<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article10_02_04_2224241</id>
	<title>Keep SSH Sessions Active, Or Reconnect?</title>
	<author>timothy</author>
	<datestamp>1265282580000</datestamp>
	<htmltext>borjonx writes <i>"Is it safer to log out of an SSH session, and re-establish it later, or just keep the connection open?  Like many of you, I use OpenSSH to connect to my Slackware Linux boxes remotely from Linux and WinXP (putty.exe) clients.  At home and at work, I wonder if it would be safer to just leave the connection open (my clients are physically secured, the servers limit connections with hosts.allow). Is it more secure to re-establish the connection over an insecure link (big bad internet) where people can sniff that handshaking, or is it more secure to just remain connected?  I connect 1 to 4 times per day, most days."</i></htmltext>
<tokenext>borjonx writes " Is it safer to log out of an SSH session , and re-establish it later , or just keep the connection open ?
Like many of you , I use OpenSSH to connect to my Slackware Linux boxes remotely from Linux and WinXP ( putty.exe ) clients .
At home and at work , I wonder if it would be safer to just leave the connection open ( my clients are physically secured , the servers limit connections with hosts.allow ) .
Is it more secure to re-establish the connection over an insecure link ( big bad internet ) where people can sniff that handshaking , or is it more secure to just remain connected ?
I connect 1 to 4 times per day , most days .
"</tokentext>
<sentencetext>borjonx writes "Is it safer to log out of an SSH session, and re-establish it later, or just keep the connection open?
Like many of you, I use OpenSSH to connect to my Slackware Linux boxes remotely from Linux and WinXP (putty.exe) clients.
At home and at work, I wonder if it would be safer to just leave the connection open (my clients are physically secured, the servers limit connections with hosts.allow).
Is it more secure to re-establish the connection over an insecure link (big bad internet) where people can sniff that handshaking, or is it more secure to just remain connected?
I connect 1 to 4 times per day, most days.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028638</id>
	<title>Reconnect.</title>
	<author>Anonymous</author>
	<datestamp>1265286600000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Seriously, reconnect.  The keys used for the encryption will change, and it's multiply keyed to boot.  Check the discussion on SSL (which SSH uses) on Steve Gibson's Security Now podcast.  <a href="http://twit.tv/sn" title="twit.tv" rel="nofollow">http://twit.tv/sn</a> [twit.tv]</p></htmltext>
<tokenext>Seriously , reconnect .
The keys used for the encryption will change , and it 's multiply keyed to boot .
Check the discussion on SSL ( which SSH uses ) on Steve Gibson 's Security Now podcast .
http : //twit.tv/sn [ twit.tv ]</tokentext>
<sentencetext>Seriously, reconnect.
The keys used for the encryption will change, and it's multiply keyed to boot.
Check the discussion on SSL (which SSH uses) on Steve Gibson's Security Now podcast.
http://twit.tv/sn [twit.tv]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31035272</id>
	<title>Re:Neither is "more" secure</title>
	<author>Dragee</author>
	<datestamp>1265389860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Who says he is blindly following advice?  In my experience, asking a large group of experienced people, many of whom are more likely to be more well-versed than I am on the topic, is an extremely valuable research technique.  It doesn't mean I'm going to blindly trust whatever I'm told; it means that I have a wealth of new, highly-relevant information with which to make my decision.  In this case, slashdot is google on steroids.</htmltext>
<tokenext>Who says he is blindly following advice ?
In my experience , asking a large group of experienced people , many of whom are more likely to be more well-versed than I am on the topic , is an extremely valuable research technique .
It does n't mean I 'm going to blindly trust whatever I 'm told ; it means that I have a wealth of new , highly-relevant information with which to make my decision .
In this case , slashdot is google on steroids .</tokentext>
<sentencetext>Who says he is blindly following advice?
In my experience, asking a large group of experienced people, many of whom are more likely to be more well-versed than I am on the topic, is an extremely valuable research technique.
It doesn't mean I'm going to blindly trust whatever I'm told; it means that I have a wealth of new, highly-relevant information with which to make my decision.
In this case, slashdot is google on steroids.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028696</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029178</id>
	<title>Boring...</title>
	<author>brundlefly</author>
	<datestamp>1265289780000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext><p>This is exactly the sort of question that Stack Overflow  was created for....</p></htmltext>
<tokenext>This is exactly the sort of question that Stack Overflow was created for... .</tokentext>
<sentencetext>This is exactly the sort of question that Stack Overflow  was created for....</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31031992</id>
	<title>More info?</title>
	<author>Wovel</author>
	<datestamp>1265313180000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>How could anyone really answer your question without knowing the value of the servers you are logged into?  If the servers you are connecting to are in a secured bunker and you are leaving the connection open from your house while your not there and the data is something valuable enough for some to break into your house.. Well then no, you should not leave the session logged in. In general it is a bad idea to leave a connection you are not using logged in.  If you are locking your workstation (you did not say), than maybe it is still ok.</p><p>Keep strict host key checking on and just log out when you are not using the box.  If the key changes and your not expecting it, either someone has already broken into your server, your DNS server (on either end), or it is time to talk to the isps on the endpoints and find out which one is out to get you. The "big bad" Internet is the least likely place for you to have a security problem, it is simply too unpredictable.</p></htmltext>
<tokenext>How could anyone really answer your question without knowing the value of the servers you are logged into ?
If the servers you are connecting to are in a secured bunker and you are leaving the connection open from your house while your not there and the data is something valuable enough for some to break into your house.. Well then no , you should not leave the session logged in .
In general it is a bad idea to leave a connection you are not using logged in .
If you are locking your workstation ( you did not say ) , than maybe it is still ok.Keep strict host key checking on and just log out when you are not using the box .
If the key changes and your not expecting it , either someone has already broken into your server , your DNS server ( on either end ) , or it is time to talk to the isps on the endpoints and find out which one is out to get you .
The " big bad " Internet is the least likely place for you to have a security problem , it is simply too unpredictable .</tokentext>
<sentencetext>How could anyone really answer your question without knowing the value of the servers you are logged into?
If the servers you are connecting to are in a secured bunker and you are leaving the connection open from your house while your not there and the data is something valuable enough for some to break into your house.. Well then no, you should not leave the session logged in.
In general it is a bad idea to leave a connection you are not using logged in.
If you are locking your workstation (you did not say), than maybe it is still ok.Keep strict host key checking on and just log out when you are not using the box.
If the key changes and your not expecting it, either someone has already broken into your server, your DNS server (on either end), or it is time to talk to the isps on the endpoints and find out which one is out to get you.
The "big bad" Internet is the least likely place for you to have a security problem, it is simply too unpredictable.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31032174</id>
	<title>Solving the wrong problem.</title>
	<author>1s44c</author>
	<datestamp>1265402820000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>I use OpenSSH to connect to my Slackware Linux boxes remotely from Linux and WinXP (putty.exe) clients.</p></div><p>You are fixing a non-problem. You should be fixing the weakest point of attack first, that being the windows machine you are connecting from.</p></div>
	</htmltext>
<tokenext>I use OpenSSH to connect to my Slackware Linux boxes remotely from Linux and WinXP ( putty.exe ) clients.You are fixing a non-problem .
You should be fixing the weakest point of attack first , that being the windows machine you are connecting from .</tokentext>
<sentencetext>I use OpenSSH to connect to my Slackware Linux boxes remotely from Linux and WinXP (putty.exe) clients.You are fixing a non-problem.
You should be fixing the weakest point of attack first, that being the windows machine you are connecting from.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028694</id>
	<title>gnu screen</title>
	<author>laktech</author>
	<datestamp>1265286840000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext>I find using the <a href="http://www.gnu.org/software/screen/screen.html" title="gnu.org" rel="nofollow">screen</a> [gnu.org] to manage my many simultaneous SSH sessions extremely helpful. This tool is so useful it's on the same level as Adblock is to Firefox.

With this tool, the reconnect/connect issue is a moot point.</htmltext>
<tokenext>I find using the screen [ gnu.org ] to manage my many simultaneous SSH sessions extremely helpful .
This tool is so useful it 's on the same level as Adblock is to Firefox .
With this tool , the reconnect/connect issue is a moot point .</tokentext>
<sentencetext>I find using the screen [gnu.org] to manage my many simultaneous SSH sessions extremely helpful.
This tool is so useful it's on the same level as Adblock is to Firefox.
With this tool, the reconnect/connect issue is a moot point.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028804</id>
	<title>How safe is your box?</title>
	<author>Anonymous</author>
	<datestamp>1265287440000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext>If you assume that the remote server is safe, and the communication is safe, then the risk could be at your own box.<br>Forgetting to set even a screensaver with password in a place where are more people (i.e. kids, or in an office ) or even not people (dont think a cat could hit rm -rf, but is your server, not mine) could make a difference in that question. Could be also an hypotetical risk of some rogue app/trojan (?) sending events to the window that have the ssh session too, but odds are somewhat low.</htmltext>
<tokenext>If you assume that the remote server is safe , and the communication is safe , then the risk could be at your own box.Forgetting to set even a screensaver with password in a place where are more people ( i.e .
kids , or in an office ) or even not people ( dont think a cat could hit rm -rf , but is your server , not mine ) could make a difference in that question .
Could be also an hypotetical risk of some rogue app/trojan ( ?
) sending events to the window that have the ssh session too , but odds are somewhat low .</tokentext>
<sentencetext>If you assume that the remote server is safe, and the communication is safe, then the risk could be at your own box.Forgetting to set even a screensaver with password in a place where are more people (i.e.
kids, or in an office ) or even not people (dont think a cat could hit rm -rf, but is your server, not mine) could make a difference in that question.
Could be also an hypotetical risk of some rogue app/trojan (?
) sending events to the window that have the ssh session too, but odds are somewhat low.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31032386</id>
	<title>NONSENSE</title>
	<author>BugHappy</author>
	<datestamp>1265362620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>"Is it more secure to re-establish the connection or to just remain connected? I connect 1 to 4 times per day, most days."
<br> <br>
Since you make new connections on a regulary basis the question does not makes sense: either way, <b>your encryption keys are likely to be known in advance</b> by your opponents (even before you start a new connection).

If you have anything worth being protected, start questionning yourself about the very simple steps you are following to transmit your data (and where it made sense for opponents to dig into).</htmltext>
<tokenext>" Is it more secure to re-establish the connection or to just remain connected ?
I connect 1 to 4 times per day , most days .
" Since you make new connections on a regulary basis the question does not makes sense : either way , your encryption keys are likely to be known in advance by your opponents ( even before you start a new connection ) .
If you have anything worth being protected , start questionning yourself about the very simple steps you are following to transmit your data ( and where it made sense for opponents to dig into ) .</tokentext>
<sentencetext>"Is it more secure to re-establish the connection or to just remain connected?
I connect 1 to 4 times per day, most days.
"
 
Since you make new connections on a regulary basis the question does not makes sense: either way, your encryption keys are likely to be known in advance by your opponents (even before you start a new connection).
If you have anything worth being protected, start questionning yourself about the very simple steps you are following to transmit your data (and where it made sense for opponents to dig into).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31032950</id>
	<title>Re:Don't leave your computer turned on.</title>
	<author>Anonymous</author>
	<datestamp>1265370180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>See, the first thing you need to understand is that tere is no computer.</p></htmltext>
<tokenext>See , the first thing you need to understand is that tere is no computer .</tokentext>
<sentencetext>See, the first thing you need to understand is that tere is no computer.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028910</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029144</id>
	<title>In your situation</title>
	<author>mindstrm</author>
	<datestamp>1265289540000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>Reconnect.  Leaving the sessions constantly open means if your workstation is compromised, you may have compromised the servers as well.... at least you've increased the risk profile of the servers.</p><p>Connect as needed - use proper key management and passwords, etc.</p></htmltext>
<tokenext>Reconnect .
Leaving the sessions constantly open means if your workstation is compromised , you may have compromised the servers as well.... at least you 've increased the risk profile of the servers.Connect as needed - use proper key management and passwords , etc .</tokentext>
<sentencetext>Reconnect.
Leaving the sessions constantly open means if your workstation is compromised, you may have compromised the servers as well.... at least you've increased the risk profile of the servers.Connect as needed - use proper key management and passwords, etc.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028702</id>
	<title>One Way to Prevent Session Hijacking</title>
	<author>Anonymous</author>
	<datestamp>1265286900000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Intuitively, longer sessions can lead to <a href="http://www.codinghorror.com/blog/archives/001100.html" title="codinghorror.com" rel="nofollow">session hijacking</a> [codinghorror.com]. This implies that it's safer to reconnect. I'm sure ssh has some way to prevent session hijacking though.</htmltext>
<tokenext>Intuitively , longer sessions can lead to session hijacking [ codinghorror.com ] .
This implies that it 's safer to reconnect .
I 'm sure ssh has some way to prevent session hijacking though .</tokentext>
<sentencetext>Intuitively, longer sessions can lead to session hijacking [codinghorror.com].
This implies that it's safer to reconnect.
I'm sure ssh has some way to prevent session hijacking though.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028766</id>
	<title>You say either, I say either...</title>
	<author>slushdork</author>
	<datestamp>1265287200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It doesn't matter either way. Barring some unknown bug in the SSH implementations (or, even more unlikely, the underlying SSH 2 protocol, or, yet even more unlikely, the under-underlying encryption mechanisms), you can stay logged in or keep re-loging in - both methods should provide no information to an attacker.
<p>
Even if there were unknown bugs, you still wouldn't be able to decide: staying logged in gives the attacker more encrypted material to analyze from the same session &amp; keys. Re-loging in every 10 minutes gives them more handshake data.
</p><p>
By the way, I hope that hosts.allow is not the only way you're protecting your servers from the "big bad internet"...</p></htmltext>
<tokenext>It does n't matter either way .
Barring some unknown bug in the SSH implementations ( or , even more unlikely , the underlying SSH 2 protocol , or , yet even more unlikely , the under-underlying encryption mechanisms ) , you can stay logged in or keep re-loging in - both methods should provide no information to an attacker .
Even if there were unknown bugs , you still would n't be able to decide : staying logged in gives the attacker more encrypted material to analyze from the same session &amp; keys .
Re-loging in every 10 minutes gives them more handshake data .
By the way , I hope that hosts.allow is not the only way you 're protecting your servers from the " big bad internet " .. .</tokentext>
<sentencetext>It doesn't matter either way.
Barring some unknown bug in the SSH implementations (or, even more unlikely, the underlying SSH 2 protocol, or, yet even more unlikely, the under-underlying encryption mechanisms), you can stay logged in or keep re-loging in - both methods should provide no information to an attacker.
Even if there were unknown bugs, you still wouldn't be able to decide: staying logged in gives the attacker more encrypted material to analyze from the same session &amp; keys.
Re-loging in every 10 minutes gives them more handshake data.
By the way, I hope that hosts.allow is not the only way you're protecting your servers from the "big bad internet"...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31032618</id>
	<title>Re:</title>
	<author>clint999</author>
	<datestamp>1265365800000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext><p>If an adversary has enough access to read/write to the socket that ssh-agent is processing or read the memory space that it is running in, then they probally also have enough access to keylog you typing in the passphrase or read ~/.ssh/id\_dsa</p></htmltext>
<tokenext>If an adversary has enough access to read/write to the socket that ssh-agent is processing or read the memory space that it is running in , then they probally also have enough access to keylog you typing in the passphrase or read ~ /.ssh/id \ _dsa</tokentext>
<sentencetext>If an adversary has enough access to read/write to the socket that ssh-agent is processing or read the memory space that it is running in, then they probally also have enough access to keylog you typing in the passphrase or read ~/.ssh/id\_dsa</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31033430</id>
	<title>Re:How safe is your box?</title>
	<author>wolftone</author>
	<datestamp>1265377080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Is it bad that I've remapped the Caps Lock key to send rm -rf?</htmltext>
<tokenext>Is it bad that I 've remapped the Caps Lock key to send rm -rf ?</tokentext>
<sentencetext>Is it bad that I've remapped the Caps Lock key to send rm -rf?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028804</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029314</id>
	<title>Re:Don't leave your computer turned on.</title>
	<author>zippthorne</author>
	<datestamp>1265290680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You can just click through that?  There's an easier way than going into<nobr> <wbr></nobr>.ssh/known\_keys and deleting the offending line?</p><p>I thought it was like that to force you to think about why the host you're connecting with might be presenting you with a new key...</p></htmltext>
<tokenext>You can just click through that ?
There 's an easier way than going into .ssh/known \ _keys and deleting the offending line ? I thought it was like that to force you to think about why the host you 're connecting with might be presenting you with a new key.. .</tokentext>
<sentencetext>You can just click through that?
There's an easier way than going into .ssh/known\_keys and deleting the offending line?I thought it was like that to force you to think about why the host you're connecting with might be presenting you with a new key...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028910</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31032294</id>
	<title>Keep SSH connected.</title>
	<author>Anonymous</author>
	<datestamp>1265361540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>SSH exchanges new session keys ones in a while (every hour?). So you are no more at risk just cause you keep connected.<br>Program that figures out session keys, need a lot of network packages. The less you send (during the use of one session key) the less they can get.</p><p>Private/Public key is not unsecure and the handshake is safe. No one will hijack you connection if you are careful about how you distribute your keys.<br>*Do not only use Password Login, if you want to be secure*<br>*Do not have a guessable password on the server you want to connect to*<br>*If possible turn off SSH password login on server*<br>It is possible to dictionary hack a password, SSH or not.</p><p>Connect fewer times also means that you are less exposed to SSH errors in the login procedure (think: Root user replaces SSHD).<br>You also expose your KeyStore password lesser times on your own side.</p></htmltext>
<tokenext>SSH exchanges new session keys ones in a while ( every hour ? ) .
So you are no more at risk just cause you keep connected.Program that figures out session keys , need a lot of network packages .
The less you send ( during the use of one session key ) the less they can get.Private/Public key is not unsecure and the handshake is safe .
No one will hijack you connection if you are careful about how you distribute your keys .
* Do not only use Password Login , if you want to be secure * * Do not have a guessable password on the server you want to connect to * * If possible turn off SSH password login on server * It is possible to dictionary hack a password , SSH or not.Connect fewer times also means that you are less exposed to SSH errors in the login procedure ( think : Root user replaces SSHD ) .You also expose your KeyStore password lesser times on your own side .</tokentext>
<sentencetext>SSH exchanges new session keys ones in a while (every hour?).
So you are no more at risk just cause you keep connected.Program that figures out session keys, need a lot of network packages.
The less you send (during the use of one session key) the less they can get.Private/Public key is not unsecure and the handshake is safe.
No one will hijack you connection if you are careful about how you distribute your keys.
*Do not only use Password Login, if you want to be secure**Do not have a guessable password on the server you want to connect to**If possible turn off SSH password login on server*It is possible to dictionary hack a password, SSH or not.Connect fewer times also means that you are less exposed to SSH errors in the login procedure (think: Root user replaces SSHD).You also expose your KeyStore password lesser times on your own side.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028568</id>
	<title>screen</title>
	<author>Anonymous</author>
	<datestamp>1265286300000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>Just use the program, "screen", if you want to resume your sessions.</p></htmltext>
<tokenext>Just use the program , " screen " , if you want to resume your sessions .</tokentext>
<sentencetext>Just use the program, "screen", if you want to resume your sessions.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31032302</id>
	<title>For starters, can putty</title>
	<author>gujo-odori</author>
	<datestamp>1265361600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Not that there's anything wrong with putty per se (AFAIK), but the underlying platform is a concern. Sure, putty will send everything over SSH back to your Linux boxes at home, but there is more than a little malware these days that logs your keystrokes, something against which SSH cannot protect you. I would only log into the home machines from your Linux machine at work, and even then only if root belongs to you. It's unlikely your employer would be using keystroke loggers, but they could; it's not illegal if they tell you, and maybe not even if they don't. The usual boilerplate in network access policies could be interpreted to mean everything from log scanning for anomalous activity to recording everything you do.</p><p>Next, set up public/private key login and don't allow password login. I do this even within my internal network, and there are no Windows machines on it. At work, where Mac, BSD, and Linux are the majority of the boxes, of course I do it too. Those boxes may be fairly secure and there aren't a lot of Windows boxes on my part of the network, but not trusting any box you don't control is a good idea.</p><p>As far as the connection duration, I'd leave them up all the time unless there is some other operational need not to.</p></htmltext>
<tokenext>Not that there 's anything wrong with putty per se ( AFAIK ) , but the underlying platform is a concern .
Sure , putty will send everything over SSH back to your Linux boxes at home , but there is more than a little malware these days that logs your keystrokes , something against which SSH can not protect you .
I would only log into the home machines from your Linux machine at work , and even then only if root belongs to you .
It 's unlikely your employer would be using keystroke loggers , but they could ; it 's not illegal if they tell you , and maybe not even if they do n't .
The usual boilerplate in network access policies could be interpreted to mean everything from log scanning for anomalous activity to recording everything you do.Next , set up public/private key login and do n't allow password login .
I do this even within my internal network , and there are no Windows machines on it .
At work , where Mac , BSD , and Linux are the majority of the boxes , of course I do it too .
Those boxes may be fairly secure and there are n't a lot of Windows boxes on my part of the network , but not trusting any box you do n't control is a good idea.As far as the connection duration , I 'd leave them up all the time unless there is some other operational need not to .</tokentext>
<sentencetext>Not that there's anything wrong with putty per se (AFAIK), but the underlying platform is a concern.
Sure, putty will send everything over SSH back to your Linux boxes at home, but there is more than a little malware these days that logs your keystrokes, something against which SSH cannot protect you.
I would only log into the home machines from your Linux machine at work, and even then only if root belongs to you.
It's unlikely your employer would be using keystroke loggers, but they could; it's not illegal if they tell you, and maybe not even if they don't.
The usual boilerplate in network access policies could be interpreted to mean everything from log scanning for anomalous activity to recording everything you do.Next, set up public/private key login and don't allow password login.
I do this even within my internal network, and there are no Windows machines on it.
At work, where Mac, BSD, and Linux are the majority of the boxes, of course I do it too.
Those boxes may be fairly secure and there aren't a lot of Windows boxes on my part of the network, but not trusting any box you don't control is a good idea.As far as the connection duration, I'd leave them up all the time unless there is some other operational need not to.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029808</id>
	<title>Very simple consideration</title>
	<author>ls671</author>
	<datestamp>1265293560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If you log in typing in a password, it might be easier for somebody to get your password by looking over your shoulder, installing a camera in your premises or use a keyboard sniffer. In the case of password authentication, every time you log in is a weak point.</p><p>
&nbsp;</p></htmltext>
<tokenext>If you log in typing in a password , it might be easier for somebody to get your password by looking over your shoulder , installing a camera in your premises or use a keyboard sniffer .
In the case of password authentication , every time you log in is a weak point .
 </tokentext>
<sentencetext>If you log in typing in a password, it might be easier for somebody to get your password by looking over your shoulder, installing a camera in your premises or use a keyboard sniffer.
In the case of password authentication, every time you log in is a weak point.
 </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31032856</id>
	<title>use vpn and ssh over the vpn</title>
	<author>Anonymous</author>
	<datestamp>1265368620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I run a Gnu Virtual Private Ethernet and change the host keys every 2 weeks. And 90\% of my ssh sessions go over the VPN.<br>For access outside of my vpn I run ssh on non standard port and change that regularly too.<br>Also you may opt not to use password authentication for ssh.</p></htmltext>
<tokenext>I run a Gnu Virtual Private Ethernet and change the host keys every 2 weeks .
And 90 \ % of my ssh sessions go over the VPN.For access outside of my vpn I run ssh on non standard port and change that regularly too.Also you may opt not to use password authentication for ssh .</tokentext>
<sentencetext>I run a Gnu Virtual Private Ethernet and change the host keys every 2 weeks.
And 90\% of my ssh sessions go over the VPN.For access outside of my vpn I run ssh on non standard port and change that regularly too.Also you may opt not to use password authentication for ssh.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31032644</id>
	<title>Why hosts.allow?</title>
	<author>Bert64</author>
	<datestamp>1265366040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Why use hosts.allow? isn't that a rather old and crufty way of doing it...<br>How about using iptables rules to allow certain hosts instead, that way someone who isn't authorised to connect won't even see the ssh service port open and won't be able to cause load on your machine by repeatedly trying to connect.</p></htmltext>
<tokenext>Why use hosts.allow ?
is n't that a rather old and crufty way of doing it...How about using iptables rules to allow certain hosts instead , that way someone who is n't authorised to connect wo n't even see the ssh service port open and wo n't be able to cause load on your machine by repeatedly trying to connect .</tokentext>
<sentencetext>Why use hosts.allow?
isn't that a rather old and crufty way of doing it...How about using iptables rules to allow certain hosts instead, that way someone who isn't authorised to connect won't even see the ssh service port open and won't be able to cause load on your machine by repeatedly trying to connect.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31031450</id>
	<title>There is no answer..</title>
	<author>invalid216</author>
	<datestamp>1265307660000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>In my opinion there is no answer to this question. Both scenarios are subject to an equal amount of risk. The most important thing is securing the workstation itself. If done properly, the risks of staying connected or re-connecting are self-canceling. Do what is most convenient for you, just make sure your workstation is as secure as it can be.</htmltext>
<tokenext>In my opinion there is no answer to this question .
Both scenarios are subject to an equal amount of risk .
The most important thing is securing the workstation itself .
If done properly , the risks of staying connected or re-connecting are self-canceling .
Do what is most convenient for you , just make sure your workstation is as secure as it can be .</tokentext>
<sentencetext>In my opinion there is no answer to this question.
Both scenarios are subject to an equal amount of risk.
The most important thing is securing the workstation itself.
If done properly, the risks of staying connected or re-connecting are self-canceling.
Do what is most convenient for you, just make sure your workstation is as secure as it can be.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31032368</id>
	<title>getting your name on /.</title>
	<author>Anonymous</author>
	<datestamp>1265362320000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Seriously, is this really a question or just wasting everyones time. I *know* you want to get your name on slashdot but at least come up with something constructive to ask.</p><p>In other news, I just had a shit, is it safer to wipe or air dry??</p></htmltext>
<tokenext>Seriously , is this really a question or just wasting everyones time .
I * know * you want to get your name on slashdot but at least come up with something constructive to ask.In other news , I just had a shit , is it safer to wipe or air dry ?
?</tokentext>
<sentencetext>Seriously, is this really a question or just wasting everyones time.
I *know* you want to get your name on slashdot but at least come up with something constructive to ask.In other news, I just had a shit, is it safer to wipe or air dry?
?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31031108</id>
	<title>Re:Neither is "more" secure</title>
	<author>drinkypoo</author>
	<datestamp>1265305140000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>If I told you that it is far more secure to leave your connection open all day, would you take my word for it?</p></div><p>He didn't ask <em>you</em>, he asked Slashdot. If everyone reputable tells him the same thing, he can probably believe it. If he had time to become a security expert, he probably would have. There are of course no certainties in life, but generally speaking, you can trust the experts most of the time. Amusingly enough, many of the experts seem to have plenty of time to read Slashdot, and even post occasionally<nobr> <wbr></nobr>:)</p></div>
	</htmltext>
<tokenext>If I told you that it is far more secure to leave your connection open all day , would you take my word for it ? He did n't ask you , he asked Slashdot .
If everyone reputable tells him the same thing , he can probably believe it .
If he had time to become a security expert , he probably would have .
There are of course no certainties in life , but generally speaking , you can trust the experts most of the time .
Amusingly enough , many of the experts seem to have plenty of time to read Slashdot , and even post occasionally : )</tokentext>
<sentencetext>If I told you that it is far more secure to leave your connection open all day, would you take my word for it?He didn't ask you, he asked Slashdot.
If everyone reputable tells him the same thing, he can probably believe it.
If he had time to become a security expert, he probably would have.
There are of course no certainties in life, but generally speaking, you can trust the experts most of the time.
Amusingly enough, many of the experts seem to have plenty of time to read Slashdot, and even post occasionally :)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028696</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029448</id>
	<title>Better to disconnect</title>
	<author>Raul Acevedo</author>
	<datestamp>1265291520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Unless you lock your desktop every single time you get up and walk away from your desk, it's better to generally disconnect, because you lessen the (admittedly very small odds) that someone else will simply walk up to your workstation, and either out of malice, curiosity or just mistake (they think you are logged in someplace it's ok for them to poke around), they end up accessing your remote session.</p><p>It may also look suspicious to sysadmins that you keep sessions alive for so long.</p><p>Is it possible for a Windows admin to poke around your desktop, remotely, without your knowledge?  I believe they normally have to make a request that you accept before you hand over control of your desktop to a Windows admin, but I don't know if Windows (or other corporate monitoring software) allows this to happen without your knowledge.</p></htmltext>
<tokenext>Unless you lock your desktop every single time you get up and walk away from your desk , it 's better to generally disconnect , because you lessen the ( admittedly very small odds ) that someone else will simply walk up to your workstation , and either out of malice , curiosity or just mistake ( they think you are logged in someplace it 's ok for them to poke around ) , they end up accessing your remote session.It may also look suspicious to sysadmins that you keep sessions alive for so long.Is it possible for a Windows admin to poke around your desktop , remotely , without your knowledge ?
I believe they normally have to make a request that you accept before you hand over control of your desktop to a Windows admin , but I do n't know if Windows ( or other corporate monitoring software ) allows this to happen without your knowledge .</tokentext>
<sentencetext>Unless you lock your desktop every single time you get up and walk away from your desk, it's better to generally disconnect, because you lessen the (admittedly very small odds) that someone else will simply walk up to your workstation, and either out of malice, curiosity or just mistake (they think you are logged in someplace it's ok for them to poke around), they end up accessing your remote session.It may also look suspicious to sysadmins that you keep sessions alive for so long.Is it possible for a Windows admin to poke around your desktop, remotely, without your knowledge?
I believe they normally have to make a request that you accept before you hand over control of your desktop to a Windows admin, but I don't know if Windows (or other corporate monitoring software) allows this to happen without your knowledge.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028656</id>
	<title>Catch 22</title>
	<author>SnoopJeDi</author>
	<datestamp>1265286660000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>If it's an "insecure link" (which is the whole reason SSH was developed ANYWAY), then ANY connection is technically compromised.

You can't just assume one that was established "sometime before" is more secure than a new one now.  If you carry your assumptions through consistently, they're both compromised and you should just disconnect.</htmltext>
<tokenext>If it 's an " insecure link " ( which is the whole reason SSH was developed ANYWAY ) , then ANY connection is technically compromised .
You ca n't just assume one that was established " sometime before " is more secure than a new one now .
If you carry your assumptions through consistently , they 're both compromised and you should just disconnect .</tokentext>
<sentencetext>If it's an "insecure link" (which is the whole reason SSH was developed ANYWAY), then ANY connection is technically compromised.
You can't just assume one that was established "sometime before" is more secure than a new one now.
If you carry your assumptions through consistently, they're both compromised and you should just disconnect.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31058024</id>
	<title>Re:Depends...</title>
	<author>Hurricane78</author>
	<datestamp>1265564820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Pff. If they get your password it&rsquo;s still over!<br>You know. A good hard lead pipe can take care of that.<nobr> <wbr></nobr>;)</p><p>I recommend having two-factor authentication. With a USB stick that contains a encrypted keyfile. Only the keyfile will decrypt the house.<br>So if they catch you, destroy you USB stick. and if they get your USB stick, destroy yourself (not the hookers and blow style. more the blow to the head style).</p><p>Now they can only get you, if they catch you and your USB stick at the same time, without you being able to destroy it.<br>So it has to destroy itself automatically, unless you constantly prevent that.</p><p>But how to do that, without the enemy also knowing how to prevent that?<nobr> <wbr></nobr>;)</p></htmltext>
<tokenext>Pff .
If they get your password it    s still over ! You know .
A good hard lead pipe can take care of that .
; ) I recommend having two-factor authentication .
With a USB stick that contains a encrypted keyfile .
Only the keyfile will decrypt the house.So if they catch you , destroy you USB stick .
and if they get your USB stick , destroy yourself ( not the hookers and blow style .
more the blow to the head style ) .Now they can only get you , if they catch you and your USB stick at the same time , without you being able to destroy it.So it has to destroy itself automatically , unless you constantly prevent that.But how to do that , without the enemy also knowing how to prevent that ?
; )</tokentext>
<sentencetext>Pff.
If they get your password it’s still over!You know.
A good hard lead pipe can take care of that.
;)I recommend having two-factor authentication.
With a USB stick that contains a encrypted keyfile.
Only the keyfile will decrypt the house.So if they catch you, destroy you USB stick.
and if they get your USB stick, destroy yourself (not the hookers and blow style.
more the blow to the head style).Now they can only get you, if they catch you and your USB stick at the same time, without you being able to destroy it.So it has to destroy itself automatically, unless you constantly prevent that.But how to do that, without the enemy also knowing how to prevent that?
;)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028688</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028632</id>
	<title>Neither</title>
	<author>nacturation</author>
	<datestamp>1265286600000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>Both the persistent connection and the handshake protocol to establish a new connection are completely secure for any practical purpose.  If both the server and the client are completely secure, and the connection between them is secure (via strong crypto in ssh) then pick whichever method works best for you.</p></htmltext>
<tokenext>Both the persistent connection and the handshake protocol to establish a new connection are completely secure for any practical purpose .
If both the server and the client are completely secure , and the connection between them is secure ( via strong crypto in ssh ) then pick whichever method works best for you .</tokentext>
<sentencetext>Both the persistent connection and the handshake protocol to establish a new connection are completely secure for any practical purpose.
If both the server and the client are completely secure, and the connection between them is secure (via strong crypto in ssh) then pick whichever method works best for you.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31031892</id>
	<title>I would say</title>
	<author>Anonymous</author>
	<datestamp>1265311980000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>that stay connected is more secure that start connection again. Why is that? Well in any case when you initiate a connection then you do several things (DH) and also...  stay connected. And well then there are more points were things could fail. If you stay connected too long and for example you are using blowfish and transfer more than 2^64 bytes (2^128 for AES) there is an attack that abuses that. Anyway you are unlikely to transfer that much and the connect/reconnect security should be high enough to not worry about that kind of stuff.</p></htmltext>
<tokenext>that stay connected is more secure that start connection again .
Why is that ?
Well in any case when you initiate a connection then you do several things ( DH ) and also... stay connected .
And well then there are more points were things could fail .
If you stay connected too long and for example you are using blowfish and transfer more than 2 ^ 64 bytes ( 2 ^ 128 for AES ) there is an attack that abuses that .
Anyway you are unlikely to transfer that much and the connect/reconnect security should be high enough to not worry about that kind of stuff .</tokentext>
<sentencetext>that stay connected is more secure that start connection again.
Why is that?
Well in any case when you initiate a connection then you do several things (DH) and also...  stay connected.
And well then there are more points were things could fail.
If you stay connected too long and for example you are using blowfish and transfer more than 2^64 bytes (2^128 for AES) there is an attack that abuses that.
Anyway you are unlikely to transfer that much and the connect/reconnect security should be high enough to not worry about that kind of stuff.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029632</id>
	<title>Re:One Way to Prevent Session Hijacking</title>
	<author>jonaskoelker</author>
	<datestamp>1265292540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I'm sure ssh has some way to prevent session hijacking though.</p></div><p>Yes, it has.  It does cryptography.</p><p>Here's the long and short of session hijacking: when you connect to (say) facebook and type in your username and password, facebook issues you a one-time "username"---something which identifies your real username---with no associated password (or, if you will, the username is the password).</p><p>Whenever you ask for a facebook page, you send that one-time username in the clear.  Anyone who snoops your connection can read that username and reuse it to impersonate you.</p><p>If the sending of the one-time username was encrypted, this wouldn't be possible.  Like Jeff (Mr. coding horror) says, use HTTPS.</p><p>SSH encrypts everything that's sent.</p><p>(Oh, and don't listen to Jeff about computer science; a recent stackoverflow podcast made it <b>painfully</b> clear he doesn't know the first thing about automata and language theory.  He may be a great programming craftsman and/or businessman, but I find his lack of faith^Wtheoretical knowledge disturbing.)</p></div>
	</htmltext>
<tokenext>I 'm sure ssh has some way to prevent session hijacking though.Yes , it has .
It does cryptography.Here 's the long and short of session hijacking : when you connect to ( say ) facebook and type in your username and password , facebook issues you a one-time " username " ---something which identifies your real username---with no associated password ( or , if you will , the username is the password ) .Whenever you ask for a facebook page , you send that one-time username in the clear .
Anyone who snoops your connection can read that username and reuse it to impersonate you.If the sending of the one-time username was encrypted , this would n't be possible .
Like Jeff ( Mr. coding horror ) says , use HTTPS.SSH encrypts everything that 's sent .
( Oh , and do n't listen to Jeff about computer science ; a recent stackoverflow podcast made it painfully clear he does n't know the first thing about automata and language theory .
He may be a great programming craftsman and/or businessman , but I find his lack of faith ^ Wtheoretical knowledge disturbing .
)</tokentext>
<sentencetext>I'm sure ssh has some way to prevent session hijacking though.Yes, it has.
It does cryptography.Here's the long and short of session hijacking: when you connect to (say) facebook and type in your username and password, facebook issues you a one-time "username"---something which identifies your real username---with no associated password (or, if you will, the username is the password).Whenever you ask for a facebook page, you send that one-time username in the clear.
Anyone who snoops your connection can read that username and reuse it to impersonate you.If the sending of the one-time username was encrypted, this wouldn't be possible.
Like Jeff (Mr. coding horror) says, use HTTPS.SSH encrypts everything that's sent.
(Oh, and don't listen to Jeff about computer science; a recent stackoverflow podcast made it painfully clear he doesn't know the first thing about automata and language theory.
He may be a great programming craftsman and/or businessman, but I find his lack of faith^Wtheoretical knowledge disturbing.
)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028702</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028832</id>
	<title>Key Fingerprint</title>
	<author>phantomcircuit</author>
	<datestamp>1265287560000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>the only thing that is important is that you verify the public key fingerprint presented by your server to prevent MITM attacks. Aside from that there is <strong>absolutely no reason</strong> to believe the ssh protocol itself has been broken.</p></htmltext>
<tokenext>the only thing that is important is that you verify the public key fingerprint presented by your server to prevent MITM attacks .
Aside from that there is absolutely no reason to believe the ssh protocol itself has been broken .</tokentext>
<sentencetext>the only thing that is important is that you verify the public key fingerprint presented by your server to prevent MITM attacks.
Aside from that there is absolutely no reason to believe the ssh protocol itself has been broken.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028910</id>
	<title>Don't leave your computer turned on.</title>
	<author>Medievalist</author>
	<datestamp>1265287980000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><blockquote><div><p>"Is it safer to log out of an SSH session, and re-establish it later, or just keep the connection open?</p></div></blockquote><p>It's safer to log out and re-establish.  <i>UNLESS</i> you are subverting host key verification - just clicking past the big warning sign that OpenSSH throws up when it sees an unknown host key - in which case you certainly can get MITM'd.  Keep copies of your <i>public</i> (not private!) host keys on a thumb drive for use the first time you connect from an outside box.</p><blockquote><div><p>Like many of you, I use OpenSSH to connect to my Slackware Linux boxes remotely from Linux and WinXP (putty.exe) clients. At home and at work, I wonder if it would be safer to just leave the connection open (my clients are physically secured, the servers limit connections with hosts.allow). Is it more secure to re-establish the connection over an insecure link (big bad internet) where people can sniff that handshaking, or is it more secure to just remain connected? I connect 1 to 4 times per day, most days."</p></div></blockquote><p>I believe the "handshake" is a diffie-hellman key exchange.  It can't be sniffed and cracked in realtime.  On the other claw, I suppose it's theoretically possible that if you leave the connection open long enough, a determined attacker with titanic resources can brute your session key.  In reality, I personally don't think that will ever happen to you, it'd be cheaper for anyone with those kind of resources to use <a href="http://xkcd.com/538/" title="xkcd.com">the $5 wrench upside your head method.</a> [xkcd.com]</p><p>Here's something to consider:  If your computer is turned off, it's not being hacked.  If your computer is turned off, it's not getting a virus.  If your computer is turned off, nobody is sniffing your packets.  If your computer is turned off, lightning isn't blowing through the ground line of your UPS like a knife through butter and turning your motherboard into a campfire.  If your computer is turned off, a jealous colleague is not sneaking into your office and using it without leaving a login record.  If your computer is turned off, it's not part of a botnet.  If your computer is turned off, it is immune to zero-day exploits that are absolutely unstoppable by any other means.</p><p>The most secure computer is <i>turned off</i>.  Any time you don't need your computer to be turned on, just turn it off.  If everyone did this, we'd save millions of dollars (and hopefully, cut off some funding to energy suppliers who hate us).</p></div>
	</htmltext>
<tokenext>" Is it safer to log out of an SSH session , and re-establish it later , or just keep the connection open ? It 's safer to log out and re-establish .
UNLESS you are subverting host key verification - just clicking past the big warning sign that OpenSSH throws up when it sees an unknown host key - in which case you certainly can get MITM 'd .
Keep copies of your public ( not private !
) host keys on a thumb drive for use the first time you connect from an outside box.Like many of you , I use OpenSSH to connect to my Slackware Linux boxes remotely from Linux and WinXP ( putty.exe ) clients .
At home and at work , I wonder if it would be safer to just leave the connection open ( my clients are physically secured , the servers limit connections with hosts.allow ) .
Is it more secure to re-establish the connection over an insecure link ( big bad internet ) where people can sniff that handshaking , or is it more secure to just remain connected ?
I connect 1 to 4 times per day , most days .
" I believe the " handshake " is a diffie-hellman key exchange .
It ca n't be sniffed and cracked in realtime .
On the other claw , I suppose it 's theoretically possible that if you leave the connection open long enough , a determined attacker with titanic resources can brute your session key .
In reality , I personally do n't think that will ever happen to you , it 'd be cheaper for anyone with those kind of resources to use the $ 5 wrench upside your head method .
[ xkcd.com ] Here 's something to consider : If your computer is turned off , it 's not being hacked .
If your computer is turned off , it 's not getting a virus .
If your computer is turned off , nobody is sniffing your packets .
If your computer is turned off , lightning is n't blowing through the ground line of your UPS like a knife through butter and turning your motherboard into a campfire .
If your computer is turned off , a jealous colleague is not sneaking into your office and using it without leaving a login record .
If your computer is turned off , it 's not part of a botnet .
If your computer is turned off , it is immune to zero-day exploits that are absolutely unstoppable by any other means.The most secure computer is turned off .
Any time you do n't need your computer to be turned on , just turn it off .
If everyone did this , we 'd save millions of dollars ( and hopefully , cut off some funding to energy suppliers who hate us ) .</tokentext>
<sentencetext>"Is it safer to log out of an SSH session, and re-establish it later, or just keep the connection open?It's safer to log out and re-establish.
UNLESS you are subverting host key verification - just clicking past the big warning sign that OpenSSH throws up when it sees an unknown host key - in which case you certainly can get MITM'd.
Keep copies of your public (not private!
) host keys on a thumb drive for use the first time you connect from an outside box.Like many of you, I use OpenSSH to connect to my Slackware Linux boxes remotely from Linux and WinXP (putty.exe) clients.
At home and at work, I wonder if it would be safer to just leave the connection open (my clients are physically secured, the servers limit connections with hosts.allow).
Is it more secure to re-establish the connection over an insecure link (big bad internet) where people can sniff that handshaking, or is it more secure to just remain connected?
I connect 1 to 4 times per day, most days.
"I believe the "handshake" is a diffie-hellman key exchange.
It can't be sniffed and cracked in realtime.
On the other claw, I suppose it's theoretically possible that if you leave the connection open long enough, a determined attacker with titanic resources can brute your session key.
In reality, I personally don't think that will ever happen to you, it'd be cheaper for anyone with those kind of resources to use the $5 wrench upside your head method.
[xkcd.com]Here's something to consider:  If your computer is turned off, it's not being hacked.
If your computer is turned off, it's not getting a virus.
If your computer is turned off, nobody is sniffing your packets.
If your computer is turned off, lightning isn't blowing through the ground line of your UPS like a knife through butter and turning your motherboard into a campfire.
If your computer is turned off, a jealous colleague is not sneaking into your office and using it without leaving a login record.
If your computer is turned off, it's not part of a botnet.
If your computer is turned off, it is immune to zero-day exploits that are absolutely unstoppable by any other means.The most secure computer is turned off.
Any time you don't need your computer to be turned on, just turn it off.
If everyone did this, we'd save millions of dollars (and hopefully, cut off some funding to energy suppliers who hate us).
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31033464</id>
	<title>Re:Don't leave your computer turned on.</title>
	<author>Anonymous</author>
	<datestamp>1265377680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Correction: Having a computer turned off does NOT protect it from lightening strikes.  I've seen a blackened radio and fried electronics from a lightening strike that hit just outside a house.  Only unplugging it will give it full lightening protection.</p></htmltext>
<tokenext>Correction : Having a computer turned off does NOT protect it from lightening strikes .
I 've seen a blackened radio and fried electronics from a lightening strike that hit just outside a house .
Only unplugging it will give it full lightening protection .</tokentext>
<sentencetext>Correction: Having a computer turned off does NOT protect it from lightening strikes.
I've seen a blackened radio and fried electronics from a lightening strike that hit just outside a house.
Only unplugging it will give it full lightening protection.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028910</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31030188</id>
	<title>risk assessment</title>
	<author>Anonymous</author>
	<datestamp>1265296800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Assuming there is no publically known exploit, the only other risk assessable item is a theoretical unpublished exploit against the protocol.  Without any evidence to support the key-exchange being the weak point, it must then be considered that any point in the system could be weak.</p><p>If the initial one-off exchanges are exploitable, then you should minimise connections to minimise the number of theoretically exploitable packets.<br>If the on-going packets are exploitable, then you should minimise total amount of packets set over time, by minimising packets set over time.</p><p>Since leaving a session running sends more packets overall ( keep alives, etc ) , it would make sense to terminate your connections unless doing it frequently.    the mathemeticians out there can determine  the precise number of packets in a session initialisiation, and in the keepalives, and determine the official "point of minimum packet use".</p><p>Just remember this:  you can't get hacked if you are not connected.</p></htmltext>
<tokenext>Assuming there is no publically known exploit , the only other risk assessable item is a theoretical unpublished exploit against the protocol .
Without any evidence to support the key-exchange being the weak point , it must then be considered that any point in the system could be weak.If the initial one-off exchanges are exploitable , then you should minimise connections to minimise the number of theoretically exploitable packets.If the on-going packets are exploitable , then you should minimise total amount of packets set over time , by minimising packets set over time.Since leaving a session running sends more packets overall ( keep alives , etc ) , it would make sense to terminate your connections unless doing it frequently .
the mathemeticians out there can determine the precise number of packets in a session initialisiation , and in the keepalives , and determine the official " point of minimum packet use " .Just remember this : you ca n't get hacked if you are not connected .</tokentext>
<sentencetext>Assuming there is no publically known exploit, the only other risk assessable item is a theoretical unpublished exploit against the protocol.
Without any evidence to support the key-exchange being the weak point, it must then be considered that any point in the system could be weak.If the initial one-off exchanges are exploitable, then you should minimise connections to minimise the number of theoretically exploitable packets.If the on-going packets are exploitable, then you should minimise total amount of packets set over time, by minimising packets set over time.Since leaving a session running sends more packets overall ( keep alives, etc ) , it would make sense to terminate your connections unless doing it frequently.
the mathemeticians out there can determine  the precise number of packets in a session initialisiation, and in the keepalives, and determine the official "point of minimum packet use".Just remember this:  you can't get hacked if you are not connected.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31032762</id>
	<title>Edumacation</title>
	<author>Fizzl</author>
	<datestamp>1265367600000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p>Read the big red book "Applied Cryptography: Protocols, Algorithms, and Source Code in C". <a href="http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-Source/dp/0471117099/ref=sr\_1\_1?ie=UTF8&amp;s=books&amp;qid=1265363727&amp;sr=8-1" title="amazon.com">http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-Source/dp/0471117099/ref=sr\_1\_1?ie=UTF8&amp;s=books&amp;qid=1265363727&amp;sr=8-1</a> [amazon.com] Highly recommended to anyone who uses public key encryption or needs to implement VPN's, mail encryption or tunnels.</p><p>In essence, no it doesn't make any difference. However, if for example you application would communicate short commands often through public key encryption it would be more economical to use persistent connections instead of making new connections all the time. Key generation is Expensive.</p><p>Also, in you situation, just use screen.</p><p>How in the hell does retarded 'ask slashdots' make the front page, but not my submission of <a href="http://itpomminpurkaja.blogspot.com/2010/02/css-anchor-pseudo-class-concerns.html" title="blogspot.com">http://itpomminpurkaja.blogspot.com/2010/02/css-anchor-pseudo-class-concerns.html</a> [blogspot.com] and <a href="http://www.fizzl.net/" title="fizzl.net">http://www.fizzl.net/</a> [fizzl.net] for which I actually expended some effort to create.</p></htmltext>
<tokenext>Read the big red book " Applied Cryptography : Protocols , Algorithms , and Source Code in C " .
http : //www.amazon.com/Applied-Cryptography-Protocols-Algorithms-Source/dp/0471117099/ref = sr \ _1 \ _1 ? ie = UTF8&amp;s = books&amp;qid = 1265363727&amp;sr = 8-1 [ amazon.com ] Highly recommended to anyone who uses public key encryption or needs to implement VPN 's , mail encryption or tunnels.In essence , no it does n't make any difference .
However , if for example you application would communicate short commands often through public key encryption it would be more economical to use persistent connections instead of making new connections all the time .
Key generation is Expensive.Also , in you situation , just use screen.How in the hell does retarded 'ask slashdots ' make the front page , but not my submission of http : //itpomminpurkaja.blogspot.com/2010/02/css-anchor-pseudo-class-concerns.html [ blogspot.com ] and http : //www.fizzl.net/ [ fizzl.net ] for which I actually expended some effort to create .</tokentext>
<sentencetext>Read the big red book "Applied Cryptography: Protocols, Algorithms, and Source Code in C".
http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-Source/dp/0471117099/ref=sr\_1\_1?ie=UTF8&amp;s=books&amp;qid=1265363727&amp;sr=8-1 [amazon.com] Highly recommended to anyone who uses public key encryption or needs to implement VPN's, mail encryption or tunnels.In essence, no it doesn't make any difference.
However, if for example you application would communicate short commands often through public key encryption it would be more economical to use persistent connections instead of making new connections all the time.
Key generation is Expensive.Also, in you situation, just use screen.How in the hell does retarded 'ask slashdots' make the front page, but not my submission of http://itpomminpurkaja.blogspot.com/2010/02/css-anchor-pseudo-class-concerns.html [blogspot.com] and http://www.fizzl.net/ [fizzl.net] for which I actually expended some effort to create.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028874</id>
	<title>I have a solution</title>
	<author>signingis</author>
	<datestamp>1265287740000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>Go outside.</p></htmltext>
<tokenext>Go outside .</tokentext>
<sentencetext>Go outside.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31031974</id>
	<title>i would say</title>
	<author>Anonymous</author>
	<datestamp>1265313000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>that stay connected is more secure than start connection again. Why is that? Well in any case when you initiate a connection then you do several things (DH) and also...  stay connected. And well then there are more points were things could fail. If you stay connected too long and for example you are using blowfish and transfer more than 2^64 bytes (2^128 for AES) there is an attack that abuses that. Anyway you are unlikely to transfer that much and the connect/reconnect security should be high enough to not worry about that kind of stuff.</p></htmltext>
<tokenext>that stay connected is more secure than start connection again .
Why is that ?
Well in any case when you initiate a connection then you do several things ( DH ) and also... stay connected .
And well then there are more points were things could fail .
If you stay connected too long and for example you are using blowfish and transfer more than 2 ^ 64 bytes ( 2 ^ 128 for AES ) there is an attack that abuses that .
Anyway you are unlikely to transfer that much and the connect/reconnect security should be high enough to not worry about that kind of stuff .</tokentext>
<sentencetext>that stay connected is more secure than start connection again.
Why is that?
Well in any case when you initiate a connection then you do several things (DH) and also...  stay connected.
And well then there are more points were things could fail.
If you stay connected too long and for example you are using blowfish and transfer more than 2^64 bytes (2^128 for AES) there is an attack that abuses that.
Anyway you are unlikely to transfer that much and the connect/reconnect security should be high enough to not worry about that kind of stuff.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029226</id>
	<title>Re:One Way to Prevent Session Hijacking</title>
	<author>Vairon</author>
	<datestamp>1265290140000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>The ask slashdot article is about SSH NOT SSL. Session hijacking has nothing to do with SSH.</p></htmltext>
<tokenext>The ask slashdot article is about SSH NOT SSL .
Session hijacking has nothing to do with SSH .</tokentext>
<sentencetext>The ask slashdot article is about SSH NOT SSL.
Session hijacking has nothing to do with SSH.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028702</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31033488</id>
	<title>Re:I have a solution</title>
	<author>Anonymous</author>
	<datestamp>1265378040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Are you suggesting that we should become that which we hate - mundane people who ignore all security protocols?  It's not worth it, man.</p></htmltext>
<tokenext>Are you suggesting that we should become that which we hate - mundane people who ignore all security protocols ?
It 's not worth it , man .</tokentext>
<sentencetext>Are you suggesting that we should become that which we hate - mundane people who ignore all security protocols?
It's not worth it, man.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028874</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028676</id>
	<title>all of the above</title>
	<author>larry bagina</author>
	<datestamp>1265286780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>reconnect as needed, but tunnel your ssh over an ssh session which is always active.</htmltext>
<tokenext>reconnect as needed , but tunnel your ssh over an ssh session which is always active .</tokentext>
<sentencetext>reconnect as needed, but tunnel your ssh over an ssh session which is always active.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029298</id>
	<title>Like many of us ...</title>
	<author>Lemming Mark</author>
	<datestamp>1265290560000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext><p><div class="quote"><p>Like many of you, I use OpenSSH to connect to my Slackware Linux boxes remotely</p></div><p>If many of us are connecting to your Slackware boxes, reconnecting is not your largest vulnerability!</p><p>(sorry, couldn't resist)</p></div>
	</htmltext>
<tokenext>Like many of you , I use OpenSSH to connect to my Slackware Linux boxes remotelyIf many of us are connecting to your Slackware boxes , reconnecting is not your largest vulnerability !
( sorry , could n't resist )</tokentext>
<sentencetext>Like many of you, I use OpenSSH to connect to my Slackware Linux boxes remotelyIf many of us are connecting to your Slackware boxes, reconnecting is not your largest vulnerability!
(sorry, couldn't resist)
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31040424</id>
	<title>always logout</title>
	<author>Anonymous</author>
	<datestamp>1265369100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Answer: Safer to logout and re-negotiate SSH when you return.</p><p>Reason: SSH authentication negotiation is secure.<br>Reality: Physical access to your desktop is the primary concern.</p><p>Also:<br>1) setup a personal security policy. Some examples are:<br>- never know the SSH passwords. Use long random passwords and secure these locally with a strong passphrase (memorized).<br>- setup a rotation schedule for your SSH keys passphrase<br>- set your screensaver to "lock desktop" when it starts<br>- always shut your PC off at end of day (flush raw keys from memory with no exceptions)<br>- always logout (not just lock screen) when you expect to be away from your PC longer then bathroom/coffee tasks.<br>- always lock the screen when you step away for those short period breaks (bathroom/coffee)<br>- setup more then one account for personal vs business. This way you can do less secure things on the personal account which has no access to your SSH keyring.<br>- determine and follow a new password minimum criteria (like: must be at least X chars, needs alpha &amp; numeric, etc)<br>- keep backups of keys and passphrases in a very very secure place (consider a lock box)<br>- never attempt to access these machines via SSH from a Windows box (these are known to be insecure and new malware is known to go undetected for months). There is no guarantee of security no matter what steps you follow.</p><p>2) Depending on the physical security of your work environment:<br>- install Linux onto a fully encrypted Hard Drive (luks works well with Debian and can be setup on install with some distros by default)<br>- install user home directory encryption (ecryptfs works for me).<br>- use 'shred' instead of 'rm' when removing old keys/passphrase's etc.</p><p>* the reason to do these steps is to provide peace of mind in cases of physical theft.</p><p>Reasons to leave SSH connected:<br>1) it is faster to leave these SSH connections open when you later want to access them. But generally, if speed has higher priority then security for your clients... then why even worry about asking your post? I assume this is not true for you, so just don't do it. It IS worth a little extra time to do things securely.</p></htmltext>
<tokenext>Answer : Safer to logout and re-negotiate SSH when you return.Reason : SSH authentication negotiation is secure.Reality : Physical access to your desktop is the primary concern.Also : 1 ) setup a personal security policy .
Some examples are : - never know the SSH passwords .
Use long random passwords and secure these locally with a strong passphrase ( memorized ) .- setup a rotation schedule for your SSH keys passphrase- set your screensaver to " lock desktop " when it starts- always shut your PC off at end of day ( flush raw keys from memory with no exceptions ) - always logout ( not just lock screen ) when you expect to be away from your PC longer then bathroom/coffee tasks.- always lock the screen when you step away for those short period breaks ( bathroom/coffee ) - setup more then one account for personal vs business .
This way you can do less secure things on the personal account which has no access to your SSH keyring.- determine and follow a new password minimum criteria ( like : must be at least X chars , needs alpha &amp; numeric , etc ) - keep backups of keys and passphrases in a very very secure place ( consider a lock box ) - never attempt to access these machines via SSH from a Windows box ( these are known to be insecure and new malware is known to go undetected for months ) .
There is no guarantee of security no matter what steps you follow.2 ) Depending on the physical security of your work environment : - install Linux onto a fully encrypted Hard Drive ( luks works well with Debian and can be setup on install with some distros by default ) - install user home directory encryption ( ecryptfs works for me ) .- use 'shred ' instead of 'rm ' when removing old keys/passphrase 's etc .
* the reason to do these steps is to provide peace of mind in cases of physical theft.Reasons to leave SSH connected : 1 ) it is faster to leave these SSH connections open when you later want to access them .
But generally , if speed has higher priority then security for your clients... then why even worry about asking your post ?
I assume this is not true for you , so just do n't do it .
It IS worth a little extra time to do things securely .</tokentext>
<sentencetext>Answer: Safer to logout and re-negotiate SSH when you return.Reason: SSH authentication negotiation is secure.Reality: Physical access to your desktop is the primary concern.Also:1) setup a personal security policy.
Some examples are:- never know the SSH passwords.
Use long random passwords and secure these locally with a strong passphrase (memorized).- setup a rotation schedule for your SSH keys passphrase- set your screensaver to "lock desktop" when it starts- always shut your PC off at end of day (flush raw keys from memory with no exceptions)- always logout (not just lock screen) when you expect to be away from your PC longer then bathroom/coffee tasks.- always lock the screen when you step away for those short period breaks (bathroom/coffee)- setup more then one account for personal vs business.
This way you can do less secure things on the personal account which has no access to your SSH keyring.- determine and follow a new password minimum criteria (like: must be at least X chars, needs alpha &amp; numeric, etc)- keep backups of keys and passphrases in a very very secure place (consider a lock box)- never attempt to access these machines via SSH from a Windows box (these are known to be insecure and new malware is known to go undetected for months).
There is no guarantee of security no matter what steps you follow.2) Depending on the physical security of your work environment:- install Linux onto a fully encrypted Hard Drive (luks works well with Debian and can be setup on install with some distros by default)- install user home directory encryption (ecryptfs works for me).- use 'shred' instead of 'rm' when removing old keys/passphrase's etc.
* the reason to do these steps is to provide peace of mind in cases of physical theft.Reasons to leave SSH connected:1) it is faster to leave these SSH connections open when you later want to access them.
But generally, if speed has higher priority then security for your clients... then why even worry about asking your post?
I assume this is not true for you, so just don't do it.
It IS worth a little extra time to do things securely.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31034006</id>
	<title>Re:How safe is your box?</title>
	<author>barberousse</author>
	<datestamp>1265382600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>A cat might not be able to do rm -rf but I heard of a ferret able to press the delete key and the enter on a Windows box.  The recycled bin saved the day but the fact is a ferret was able to delete a file by running on a keyboard.</p></htmltext>
<tokenext>A cat might not be able to do rm -rf but I heard of a ferret able to press the delete key and the enter on a Windows box .
The recycled bin saved the day but the fact is a ferret was able to delete a file by running on a keyboard .</tokentext>
<sentencetext>A cat might not be able to do rm -rf but I heard of a ferret able to press the delete key and the enter on a Windows box.
The recycled bin saved the day but the fact is a ferret was able to delete a file by running on a keyboard.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028804</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029028</id>
	<title>keep alive of course, just in case you get fired</title>
	<author>Anonymous</author>
	<datestamp>1265288700000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>keep alive of course, just in case you get fired</p><p>they might change passwords, regenerate keys, restarts sshd, but by default sshd does not drop existing connections<nobr> <wbr></nobr>;-)</p><p>so, when when you get home, all depressed, you sit down in front of your computer, the screen comes on, and you go "hey, I am still logged in"</p><p>then with a smirk on your face, you can still go to work</p><p>next few days when they call you that you are hired back, send them your consulting rate (3-4X your regular salary)</p><p>dont you read BOFH to know this?</p></htmltext>
<tokenext>keep alive of course , just in case you get firedthey might change passwords , regenerate keys , restarts sshd , but by default sshd does not drop existing connections ; - ) so , when when you get home , all depressed , you sit down in front of your computer , the screen comes on , and you go " hey , I am still logged in " then with a smirk on your face , you can still go to worknext few days when they call you that you are hired back , send them your consulting rate ( 3-4X your regular salary ) dont you read BOFH to know this ?</tokentext>
<sentencetext>keep alive of course, just in case you get firedthey might change passwords, regenerate keys, restarts sshd, but by default sshd does not drop existing connections ;-)so, when when you get home, all depressed, you sit down in front of your computer, the screen comes on, and you go "hey, I am still logged in"then with a smirk on your face, you can still go to worknext few days when they call you that you are hired back, send them your consulting rate (3-4X your regular salary)dont you read BOFH to know this?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31030798</id>
	<title>tag: youarentthatimportant - WTF?</title>
	<author>wvmarle</author>
	<datestamp>1265302680000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>Come on people what is this? Tagging such a story where someone asks about some security where some obscure attack may be possible and then tagging it "you aren't that important"?!
</p><p>This is the same messageboard that wants https for everything, even for this board.
</p><p>This is the same board that seems to hold privacy above all.
</p><p>And on top of it, it is full of nerds that tend to love to go into this kind of obscure detail.
</p><p>And then tag it "you aren't that important" implying "what are you worried about", or with a little further stretch "you have nothing to hide, so don't bother". This is quite ridiculous.
</p><p>To me I am the most important person in the world, and I would like to live safe and secure. The poster is likely the most important person to himself, and he also wishes to live safe and secure. I wouldn't go as far as poster does, but that's besides the point. He does want to go this far, and has a genuine question that many may consider over the top for personal security but which may have consequences for entities that are under constant attack, where any minute attack vector may mean the difference between safe and 0wned.
</p><p>"youarentthatimportant" is the worst tag I have ever seen. It's denigrating at best. It's stupid, and shows lack of respect for other people. I may hope this was intended as a joke and a joke alone.</p></htmltext>
<tokenext>Come on people what is this ?
Tagging such a story where someone asks about some security where some obscure attack may be possible and then tagging it " you are n't that important " ? !
This is the same messageboard that wants https for everything , even for this board .
This is the same board that seems to hold privacy above all .
And on top of it , it is full of nerds that tend to love to go into this kind of obscure detail .
And then tag it " you are n't that important " implying " what are you worried about " , or with a little further stretch " you have nothing to hide , so do n't bother " .
This is quite ridiculous .
To me I am the most important person in the world , and I would like to live safe and secure .
The poster is likely the most important person to himself , and he also wishes to live safe and secure .
I would n't go as far as poster does , but that 's besides the point .
He does want to go this far , and has a genuine question that many may consider over the top for personal security but which may have consequences for entities that are under constant attack , where any minute attack vector may mean the difference between safe and 0wned .
" youarentthatimportant " is the worst tag I have ever seen .
It 's denigrating at best .
It 's stupid , and shows lack of respect for other people .
I may hope this was intended as a joke and a joke alone .</tokentext>
<sentencetext>Come on people what is this?
Tagging such a story where someone asks about some security where some obscure attack may be possible and then tagging it "you aren't that important"?!
This is the same messageboard that wants https for everything, even for this board.
This is the same board that seems to hold privacy above all.
And on top of it, it is full of nerds that tend to love to go into this kind of obscure detail.
And then tag it "you aren't that important" implying "what are you worried about", or with a little further stretch "you have nothing to hide, so don't bother".
This is quite ridiculous.
To me I am the most important person in the world, and I would like to live safe and secure.
The poster is likely the most important person to himself, and he also wishes to live safe and secure.
I wouldn't go as far as poster does, but that's besides the point.
He does want to go this far, and has a genuine question that many may consider over the top for personal security but which may have consequences for entities that are under constant attack, where any minute attack vector may mean the difference between safe and 0wned.
"youarentthatimportant" is the worst tag I have ever seen.
It's denigrating at best.
It's stupid, and shows lack of respect for other people.
I may hope this was intended as a joke and a joke alone.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31030304</id>
	<title>Jesus Fucking Christ</title>
	<author>Anonymous</author>
	<datestamp>1265297940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>No way in Hell I use WinXP.  Fuck That.</p></htmltext>
<tokenext>No way in Hell I use WinXP .
Fuck That .</tokentext>
<sentencetext>No way in Hell I use WinXP.
Fuck That.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31030768</id>
	<title>Re:Neither is "more" secure</title>
	<author>Nezer</author>
	<datestamp>1265302380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I wish I had mod points. The parent is spot on.</p><p>What is effectively "more secure" is dependent on many, many variables that, ideally, should be mindfully evaluated by the end-user in real-time (and this includes accepting user-error as a risk--even the best fuck up on occasion).</p></htmltext>
<tokenext>I wish I had mod points .
The parent is spot on.What is effectively " more secure " is dependent on many , many variables that , ideally , should be mindfully evaluated by the end-user in real-time ( and this includes accepting user-error as a risk--even the best fuck up on occasion ) .</tokentext>
<sentencetext>I wish I had mod points.
The parent is spot on.What is effectively "more secure" is dependent on many, many variables that, ideally, should be mindfully evaluated by the end-user in real-time (and this includes accepting user-error as a risk--even the best fuck up on occasion).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028696</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028688</id>
	<title>Depends...</title>
	<author>Monkeedude1212</author>
	<datestamp>1265286840000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext>Are they using the interwebs to hack the mainframe, or <i>crack</i> the mainframe? You need to consider if they are after your Datasheets or your Hard-Diskette. Theres so many factors to consider. Perhaps they just want to plant a worm that will grow into a virus which will grow into a trojan, if you don't stop it in its Larval stages. You can use cyber worms and cyber Larva in some advanced Phishing techniques, so don't waste them if you come across them.

I suppose the only way to be sure 100\% secure is to encrypt your entire house on the molecular level. Before you head off to work, you should arrange each everything into 8 mol groups and hash into some kind of cipher, its the only way to be both virtually and physically secure.</htmltext>
<tokenext>Are they using the interwebs to hack the mainframe , or crack the mainframe ?
You need to consider if they are after your Datasheets or your Hard-Diskette .
Theres so many factors to consider .
Perhaps they just want to plant a worm that will grow into a virus which will grow into a trojan , if you do n't stop it in its Larval stages .
You can use cyber worms and cyber Larva in some advanced Phishing techniques , so do n't waste them if you come across them .
I suppose the only way to be sure 100 \ % secure is to encrypt your entire house on the molecular level .
Before you head off to work , you should arrange each everything into 8 mol groups and hash into some kind of cipher , its the only way to be both virtually and physically secure .</tokentext>
<sentencetext>Are they using the interwebs to hack the mainframe, or crack the mainframe?
You need to consider if they are after your Datasheets or your Hard-Diskette.
Theres so many factors to consider.
Perhaps they just want to plant a worm that will grow into a virus which will grow into a trojan, if you don't stop it in its Larval stages.
You can use cyber worms and cyber Larva in some advanced Phishing techniques, so don't waste them if you come across them.
I suppose the only way to be sure 100\% secure is to encrypt your entire house on the molecular level.
Before you head off to work, you should arrange each everything into 8 mol groups and hash into some kind of cipher, its the only way to be both virtually and physically secure.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029724</id>
	<title>Re:Catch 22</title>
	<author>slimjim8094</author>
	<datestamp>1265293080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I don't think that's the case. I'm pretty sure you can transport the host machine fingerprint to the client, and the public key to the server, and have it impossible to crack the connection without breaking the crypto.</p><p>IANACE (crypto expert) but I think the only avenue for MITM is on the *first* connection to the host, where you need to trust that the link is secure enough to not modify the fingerprint. If you don't need to trust that... I think you're safe.</p></htmltext>
<tokenext>I do n't think that 's the case .
I 'm pretty sure you can transport the host machine fingerprint to the client , and the public key to the server , and have it impossible to crack the connection without breaking the crypto.IANACE ( crypto expert ) but I think the only avenue for MITM is on the * first * connection to the host , where you need to trust that the link is secure enough to not modify the fingerprint .
If you do n't need to trust that... I think you 're safe .</tokentext>
<sentencetext>I don't think that's the case.
I'm pretty sure you can transport the host machine fingerprint to the client, and the public key to the server, and have it impossible to crack the connection without breaking the crypto.IANACE (crypto expert) but I think the only avenue for MITM is on the *first* connection to the host, where you need to trust that the link is secure enough to not modify the fingerprint.
If you don't need to trust that... I think you're safe.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028656</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31031850</id>
	<title>Re:Restarting makes traffic analysis a little easi</title>
	<author>Anonymous</author>
	<datestamp>1265311560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Davis</p></htmltext>
<tokenext>Davis</tokentext>
<sentencetext>Davis</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029244</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31030284</id>
	<title>Re:Don't leave your computer turned on.</title>
	<author>Anonymous</author>
	<datestamp>1265297760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>If your computer is turned off, lightning isn't blowing through the ground line of your UPS like a knife through butter and turning your motherboard into a campfire.</p></div><p>Actually nothing short of unplugging it will prevent that.  But the odds are pretty small.</p></div>
	</htmltext>
<tokenext>If your computer is turned off , lightning is n't blowing through the ground line of your UPS like a knife through butter and turning your motherboard into a campfire.Actually nothing short of unplugging it will prevent that .
But the odds are pretty small .</tokentext>
<sentencetext>If your computer is turned off, lightning isn't blowing through the ground line of your UPS like a knife through butter and turning your motherboard into a campfire.Actually nothing short of unplugging it will prevent that.
But the odds are pretty small.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028910</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31033890</id>
	<title>What you really need</title>
	<author>morgauxo</author>
	<datestamp>1265381580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Is a really long RS232 cable.  Stretch it between your home and work.</htmltext>
<tokenext>Is a really long RS232 cable .
Stretch it between your home and work .</tokentext>
<sentencetext>Is a really long RS232 cable.
Stretch it between your home and work.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31032204</id>
	<title>Re:I have a solution</title>
	<author>rastos1</author>
	<datestamp>1265403240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Go outside.</p></div></blockquote><p>

Don't. You are likely to be eaten by a grue.</p></div>
	</htmltext>
<tokenext>Go outside .
Do n't. You are likely to be eaten by a grue .</tokentext>
<sentencetext>Go outside.
Don't. You are likely to be eaten by a grue.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028874</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028870</id>
	<title>Depends where you're connecting from</title>
	<author>bram</author>
	<datestamp>1265287740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If you're connecting with putty it implies starting of from a risky platform.</p><p>Otherwise it wouldn't make a big difference.<br>With enough resources session keys can probably be replayed either way.</p></htmltext>
<tokenext>If you 're connecting with putty it implies starting of from a risky platform.Otherwise it would n't make a big difference.With enough resources session keys can probably be replayed either way .</tokentext>
<sentencetext>If you're connecting with putty it implies starting of from a risky platform.Otherwise it wouldn't make a big difference.With enough resources session keys can probably be replayed either way.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31032326</id>
	<title>said a different way...</title>
	<author>Youngbull</author>
	<datestamp>1265361900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>"Is it safer to stay in the car, or is it safe to go outside? Like many of you, I use a car to go to work and whatnot. At home and at work, I wonder if it would be safer to just stay in the car then going outside. Is it more secure to lock my car with a key (big bad parking lot) where people can come up and steal my keys, or is it more secure to just remain in the car? I use my car 1 to 4 times per day, most days."  

On a serious note; when you have used so much time to secure your connection why not used now and then.</htmltext>
<tokenext>" Is it safer to stay in the car , or is it safe to go outside ?
Like many of you , I use a car to go to work and whatnot .
At home and at work , I wonder if it would be safer to just stay in the car then going outside .
Is it more secure to lock my car with a key ( big bad parking lot ) where people can come up and steal my keys , or is it more secure to just remain in the car ?
I use my car 1 to 4 times per day , most days .
" On a serious note ; when you have used so much time to secure your connection why not used now and then .</tokentext>
<sentencetext>"Is it safer to stay in the car, or is it safe to go outside?
Like many of you, I use a car to go to work and whatnot.
At home and at work, I wonder if it would be safer to just stay in the car then going outside.
Is it more secure to lock my car with a key (big bad parking lot) where people can come up and steal my keys, or is it more secure to just remain in the car?
I use my car 1 to 4 times per day, most days.
"  

On a serious note; when you have used so much time to secure your connection why not used now and then.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31030050</id>
	<title>Exposure window. A real issue to consider</title>
	<author>suso</author>
	<datestamp>1265295540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Other than looking at the protocol itself, there is one other thing to consider that may raise the stakes more than someone's ability to crack SSH or not.  By keeping yourself logged in and using a keep alive option such as TCPKeepAlive, you are further exposing your existence.  If someone was listening at a router or something and wanted to find interesting hosts to break into, you're opening a larger window for discovery by leaving your session logged into 24x7.  The fact that you're using SSH would tell someone that you have shell accounts in different places, which is most definitely interesting to hackers.</p></htmltext>
<tokenext>Other than looking at the protocol itself , there is one other thing to consider that may raise the stakes more than someone 's ability to crack SSH or not .
By keeping yourself logged in and using a keep alive option such as TCPKeepAlive , you are further exposing your existence .
If someone was listening at a router or something and wanted to find interesting hosts to break into , you 're opening a larger window for discovery by leaving your session logged into 24x7 .
The fact that you 're using SSH would tell someone that you have shell accounts in different places , which is most definitely interesting to hackers .</tokentext>
<sentencetext>Other than looking at the protocol itself, there is one other thing to consider that may raise the stakes more than someone's ability to crack SSH or not.
By keeping yourself logged in and using a keep alive option such as TCPKeepAlive, you are further exposing your existence.
If someone was listening at a router or something and wanted to find interesting hosts to break into, you're opening a larger window for discovery by leaving your session logged into 24x7.
The fact that you're using SSH would tell someone that you have shell accounts in different places, which is most definitely interesting to hackers.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028696</id>
	<title>Neither is "more" secure</title>
	<author>Anonymous</author>
	<datestamp>1265286900000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>It is good that you are concerned about security. It is bad that you are asking Slashdot for security advice.</p><p>If I told you that it is far more secure to leave your connection open all day, would you take my word for it?</p><p>Do some research on the subject. Learn what terms like IND-CPA, IND-CCA, and IND-CCA2 mean and how to evaluate this situation for yourself. In terms of security, blindly following someone's advice is the less secure choice.</p></htmltext>
<tokenext>It is good that you are concerned about security .
It is bad that you are asking Slashdot for security advice.If I told you that it is far more secure to leave your connection open all day , would you take my word for it ? Do some research on the subject .
Learn what terms like IND-CPA , IND-CCA , and IND-CCA2 mean and how to evaluate this situation for yourself .
In terms of security , blindly following someone 's advice is the less secure choice .</tokentext>
<sentencetext>It is good that you are concerned about security.
It is bad that you are asking Slashdot for security advice.If I told you that it is far more secure to leave your connection open all day, would you take my word for it?Do some research on the subject.
Learn what terms like IND-CPA, IND-CCA, and IND-CCA2 mean and how to evaluate this situation for yourself.
In terms of security, blindly following someone's advice is the less secure choice.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31031402</id>
	<title>VPN/Tunnel</title>
	<author>inhuman\_4</author>
	<datestamp>1265307240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If you are really worried about having an insecure link you could try creating a tunnel or VPN between the two machines. These can be long term connections setup indefinitely and have provide their own layer of security. Then just make sure you SSH through the VPN/Tunnel to get back to the server. This will protect your hand shaking between the two systems.</p><p>Also be sure to have you private/public keys setup. For ease of use they do not need to have a password (although they can), which is handy for using scp.</p><p>However this seems like overkill to me. I am in a similar situation where I SSH home, but because I am a small time home user I find the security provided by SSH and private/public key encryption good enough for me.</p></htmltext>
<tokenext>If you are really worried about having an insecure link you could try creating a tunnel or VPN between the two machines .
These can be long term connections setup indefinitely and have provide their own layer of security .
Then just make sure you SSH through the VPN/Tunnel to get back to the server .
This will protect your hand shaking between the two systems.Also be sure to have you private/public keys setup .
For ease of use they do not need to have a password ( although they can ) , which is handy for using scp.However this seems like overkill to me .
I am in a similar situation where I SSH home , but because I am a small time home user I find the security provided by SSH and private/public key encryption good enough for me .</tokentext>
<sentencetext>If you are really worried about having an insecure link you could try creating a tunnel or VPN between the two machines.
These can be long term connections setup indefinitely and have provide their own layer of security.
Then just make sure you SSH through the VPN/Tunnel to get back to the server.
This will protect your hand shaking between the two systems.Also be sure to have you private/public keys setup.
For ease of use they do not need to have a password (although they can), which is handy for using scp.However this seems like overkill to me.
I am in a similar situation where I SSH home, but because I am a small time home user I find the security provided by SSH and private/public key encryption good enough for me.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029244</id>
	<title>Restarting makes traffic analysis a little easier.</title>
	<author>dweller\_below</author>
	<datestamp>1265290260000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>I do IT Security for a university. One of my projects is to do some rudimentary traffic analysis of our SSH sessions.</p><p>I look for the negotiation between SSH server and client and log connections. Since the negotiation is port independent, I can log the start of SSH sessions, no matter what port they are on. This allows me to:</p><p>1) Notice if important systems have sprung a new SSH backdoor.<br>2) Notice if important systems are SSH'ing out to weird places.<br>3) Check with local sys-admins and say things like: 'Looks like the Chinese have found your supersecret SSH port. Again. You have proved that TCP/222 and TCP/2222 are not good choices. Maybe this time you want to borrow my HexDice?'</p><p>Anywho, my rudimentary traffic analysis can be defeated if you change the SSH negotiation. It can be hindered if you just leave the connections running for days at a time.</p><p>So, if you want to annoy people like me, you may want to leave the connections up.</p><p>Miles</p></htmltext>
<tokenext>I do IT Security for a university .
One of my projects is to do some rudimentary traffic analysis of our SSH sessions.I look for the negotiation between SSH server and client and log connections .
Since the negotiation is port independent , I can log the start of SSH sessions , no matter what port they are on .
This allows me to : 1 ) Notice if important systems have sprung a new SSH backdoor.2 ) Notice if important systems are SSH'ing out to weird places.3 ) Check with local sys-admins and say things like : 'Looks like the Chinese have found your supersecret SSH port .
Again. You have proved that TCP/222 and TCP/2222 are not good choices .
Maybe this time you want to borrow my HexDice ?
'Anywho , my rudimentary traffic analysis can be defeated if you change the SSH negotiation .
It can be hindered if you just leave the connections running for days at a time.So , if you want to annoy people like me , you may want to leave the connections up.Miles</tokentext>
<sentencetext>I do IT Security for a university.
One of my projects is to do some rudimentary traffic analysis of our SSH sessions.I look for the negotiation between SSH server and client and log connections.
Since the negotiation is port independent, I can log the start of SSH sessions, no matter what port they are on.
This allows me to:1) Notice if important systems have sprung a new SSH backdoor.2) Notice if important systems are SSH'ing out to weird places.3) Check with local sys-admins and say things like: 'Looks like the Chinese have found your supersecret SSH port.
Again. You have proved that TCP/222 and TCP/2222 are not good choices.
Maybe this time you want to borrow my HexDice?
'Anywho, my rudimentary traffic analysis can be defeated if you change the SSH negotiation.
It can be hindered if you just leave the connections running for days at a time.So, if you want to annoy people like me, you may want to leave the connections up.Miles</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31047350</id>
	<title>MITM vs replay</title>
	<author>midom</author>
	<datestamp>1265488560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>One needs to stage man-in-the-middle attack to hijack existing session, whereas broken handshake can be used to establish new connections. Not looking at crypto-analysis, keeping connections open is much more secure<nobr> <wbr></nobr>;-)</htmltext>
<tokenext>One needs to stage man-in-the-middle attack to hijack existing session , whereas broken handshake can be used to establish new connections .
Not looking at crypto-analysis , keeping connections open is much more secure ; - )</tokentext>
<sentencetext>One needs to stage man-in-the-middle attack to hijack existing session, whereas broken handshake can be used to establish new connections.
Not looking at crypto-analysis, keeping connections open is much more secure ;-)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029280</id>
	<title>The vulnerability is in the endpoints</title>
	<author>Anonymous</author>
	<datestamp>1265290440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The tunnel can be considered safe, regardless of whether you reconnect often, or leave it connected.  The attack target worth considering in this case is the tunnel endpoints.  Consider that your box is owned and the remote box is not.  The remote box can only be tampered with while the tunnel is established, so leaving the ssh session active leaves you more vulnerable.  (This is only valid if establishing the tunnel requires three-factor-authentication, such that the attacker can't reestablish the tunnel at will.)</p></htmltext>
<tokenext>The tunnel can be considered safe , regardless of whether you reconnect often , or leave it connected .
The attack target worth considering in this case is the tunnel endpoints .
Consider that your box is owned and the remote box is not .
The remote box can only be tampered with while the tunnel is established , so leaving the ssh session active leaves you more vulnerable .
( This is only valid if establishing the tunnel requires three-factor-authentication , such that the attacker ca n't reestablish the tunnel at will .
)</tokentext>
<sentencetext>The tunnel can be considered safe, regardless of whether you reconnect often, or leave it connected.
The attack target worth considering in this case is the tunnel endpoints.
Consider that your box is owned and the remote box is not.
The remote box can only be tampered with while the tunnel is established, so leaving the ssh session active leaves you more vulnerable.
(This is only valid if establishing the tunnel requires three-factor-authentication, such that the attacker can't reestablish the tunnel at will.
)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028662</id>
	<title>Probably safe</title>
	<author>cl!p</author>
	<datestamp>1265286660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If the servers and clients are physically safe/locked that is. SSH renegotiates the encryption keys by default when nessesary. So even if an adversary tries to break your keys, he would have to sart over pretty soon.</htmltext>
<tokenext>If the servers and clients are physically safe/locked that is .
SSH renegotiates the encryption keys by default when nessesary .
So even if an adversary tries to break your keys , he would have to sart over pretty soon .</tokentext>
<sentencetext>If the servers and clients are physically safe/locked that is.
SSH renegotiates the encryption keys by default when nessesary.
So even if an adversary tries to break your keys, he would have to sart over pretty soon.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31033458</id>
	<title>Re:all of the above</title>
	<author>Ciaran Power</author>
	<datestamp>1265377620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Jesus, that's just Wrong.</htmltext>
<tokenext>Jesus , that 's just Wrong .</tokentext>
<sentencetext>Jesus, that's just Wrong.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028676</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_2224241_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029314
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028910
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_2224241_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029724
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028656
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_2224241_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31032950
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028910
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_2224241_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31035272
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028696
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_2224241_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31030284
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028910
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_2224241_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029632
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028702
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_2224241_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31031850
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029244
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_2224241_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31031108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028696
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_2224241_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31033464
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028910
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_2224241_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31033488
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028874
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_2224241_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31032204
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028874
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_2224241_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31033458
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028676
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_2224241_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31058024
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028688
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_2224241_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31034006
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028804
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_2224241_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029226
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028702
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_2224241_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31030768
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028696
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_2224241_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31033430
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028804
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_2224241.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028694
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_2224241.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028638
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_2224241.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028910
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029314
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31033464
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31030284
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31032950
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_2224241.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028696
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31031108
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31030768
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31035272
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_2224241.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028656
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029724
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_2224241.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31032762
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_2224241.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028568
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_2224241.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028688
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31058024
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_2224241.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028832
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_2224241.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029808
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_2224241.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028804
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31033430
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31034006
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_2224241.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029448
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_2224241.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028702
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029226
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029632
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_2224241.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31029244
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31031850
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_2224241.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31030798
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_2224241.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31031402
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_2224241.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028766
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_2224241.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028676
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31033458
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_2224241.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31028874
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31032204
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_2224241.31033488
</commentlist>
</conversation>
