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

screen

[Singularity42]

Just use the program, "screen", if you want to resume your sessions.

Re:screen

[flydpnkrtn]

Just use the program, "screen", if you want to resume your sessions.

That's not what he's asking though... "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?"

With a tinfoil hat on, he's asking if it's OK for the OpenSSH handshake to be happening 1-4 times per day across the big bad interwebs (traffic that could potentially be sniffed). He's not asking how to maintain sessions even if ssh itself is disconnected (which is what screen gives you)

Re:screen

[StudMuffin]

http://www.ubuntu.com/usn/usn-370-1

Burned by that. Prolly fixed now, but that doesn't mean I am eager to resume :D Call me old fashioned.

Re:screen

[zippthorne]

There is no need to be entering your password in every time. If you're logging in frequently, see man pages for ssh-agent, ssh-keygen, and ssh-add.

It's not that difficult to set up, although the first time takes few minutes to understand. Your OS may also have integration into its keychain, depending on what you're using.

Re:screen

[Antique Geekmeister]

The ability to read your sockets, directly, to steal the passphrase requires access during that action, with root privileges. It also requires a bit of programming knowledge. Conversely, the ssh-agent access merely requires stolen user level privileges at any time during the period that you have the agent loaded up. It's the difference between picking a lock, and looking under the doormat for the key the owner left there.

A similar issue occurs with administratively privileged sessions without a screen locked, but this is exacerbated by the casual handling of $HOME contents in numerous working environments.

Wat

[sakdoctor]

What gives you the impression that the key-exchange in SSH is vulnerable?
The short answer is: Whatever.

http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange

Re:Wat

[xZgf6xHx2uhoAj9D]

More to the point (since basic Diffie-Hellman is vulnerable to man-in-the-middle attacks), if you already have the "fingerprint" stored for your home machine, that really can't be faked, so you're safe. If you're not storing the "fingerprint" (why not?) then, well, why would anyone do that?

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.

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:Always mitigate against the most likely risk

[fm6]

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.

User error isn't merely the biggest danger. If you count social engineering exploits and sloppy procedures as "user error" than user error accounts for almost all exploits. Mathematical exploits are few and far between — "breaking the code" is something that pretty much happens only in bad spy movies.

(And yes, I know how Blechley Park "broke" Enigma. Except Enigma was never broken. Sloppy procedures by Axis radio operators made the code less secure than it should have been. As it was, they needed brilliant mathematics, early computers, and a lot of luck to even read a small portion of Enigma traffic.)

But why is connecting to the wrong machine a security breach? Because you're sending your password to somebody that shouldn't have it? Passwords themselves are poor security — nobody can remember all the passwords they need to use, and the usual methods of recording them (like the post-it attached to the monitor) are horribly insecure. If you're paranoid enough to use SSH, you should be using SSH's public key authentication.

Neither

[nacturation]

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.

Re:Reconnect.

[pthisis]

SSH doesn't use SSL, and SSHv2 has provisions for rekeying even during a single connection.

How safe is your box?

[gmuslera]

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.

Key Fingerprint

[phantomcircuit]

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.

Re:One Way to Prevent Session Hijacking

[Vairon]

The ask slashdot article is about SSH NOT SSL. Session hijacking has nothing to do with SSH.