Keep SSH Sessions Active, Or Reconnect?

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."

Comments

Always mitigate against the most likely risk

[pthisis]

Is it safer to log out of an SSH session, and re-establish it later, or just keep the connection open?

Breaking the crypto is almost assuredly not the weakest point in your connection. I'd stay connected, since by far the biggest danger is user errors: you accidentally connecting to the wrong serves, ignoring a cert change alert or something else boneheaded.

Assuming you're not using SSH1, the client and server should periodically regenerate session keys, so it's not like you'll be encrypting vast sessions with just one key (not that this is likely to be the biggest point of failure in your system even without re-keying).

Re:Wat

[hunteke]

What gives you the impression that the key-exchange in SSH is vulnerable?

Answer: The key-exchange is not vulnerable. However, there is an issue the first time you connect to one host from the other. That initial message that most people ignore is a possible MITM (Man in the Middle) avenue a cracker could harness.

Example message:

The authenticity of host 'ssh.example.com (123.234.123.234)' can't be established.
RSA key fingerprint is 96:21:c3:32:3d:cc:18:d5:53:6a:d4:0d:0d:73:c6:1a.
Are you sure you want to continue connecting (yes/no)?

While giving the password to the remote server for authentication may be secure, unless you've verified that fingerprint, you don't know to whom you're talking. That is, when you connect the first time, and you blindly accept that fingerprint, if it's a cracker, you are literally typing your password to the rogue machine (that would then turn around and log in "as you" to the real machine).

Ideally, you would to verify that fingerprint with a version you get through alternate, presumably secure, means. E.g. an over-the-phone conversation with an administrator, or physically accessing the work system and writing it down, or (temporarily) connecting directly to the server with a cross-over cable.