Slashdot Mirror
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."
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
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)
Here's to the crazy ones
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).
rage, rage against the dying of the light
Just drive a blue car if you want it to catch on fire, you mean. The ONLY time I have ever had a car catch on fire it was blue.
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.
Weaseling out of things is important to learn. It's what separates us from the animals... except the weasel. -
SSH doesn't use SSL, and SSHv2 has provisions for rekeying even during a single connection.
rage, rage against the dying of the light
This is the wrong place to ask. I doubt we'll get a single response from a person on the cutting edge of cryptanalysis who can give you a meaningful answer on the relative strength of Diffe-Hellman vs AES, which is what your question comes down to.
Realistically, it makes no difference. Both mechanisms are highly secure, cutting edge cryptographic systems. I doubt that either have been broken by anyone. If there is someone powerful enough to break those systems *and* keep the discovery secret, they're waaay above the league where they'd be interested in your SSH connections. That is, unless you work for the military of a major world power and are known to be transmitting valuable intel.
The ability to secretly break DH or AES would be such a huge weapon that they wouldn't use it unless the stakes were high enough to risk losing the advantage if their capability were detected. Somehow, I think your connections to your servers aren't that important.
I hate printers.
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.
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.
This is the wrong place to ask. I doubt we'll get a single response from a person on the cutting edge of cryptanalysis who can give you a meaningful answer on the relative strength of Diffe-Hellman vs AES, which is what your question comes down to.
No, it doesn't.
Currently, the relative strength of both of those is "much stronger than the chance of some kind of user screwup". Something like typing a password and "enter" into the wrong window, connecting to the wrong server, being tired and cranky about having to get work done and so ignoring a KEY CHANGE warning, etc is far more likely than an attacker breaking AES or Diffie-Hellman to get to your data.
So, do what you can to minimize the chance of user error. To me, that probably means stay connected (I'm willing to be persuaded otherwise, though, whether in general or for particular work patterns).
rage, rage against the dying of the light
People joke about OTP and say it's infeasible, but seriously: how inconvenient is it to carry around a few gigabytes of pad? It was infeasible 20 years ago but today it sure doesn't sound very burdensome or expensive. The thing is, it's historically so infeasible, that most of today's software doesn't bother to support it. And yet, if our software could use it, I bet plenty of people really would be carrying around randomized flash cards, just for that purpose.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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.
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
Huh? So you're saying somehow screen keeps listening on a port and lets evil hackers connect to it, exploit it, and continue using your screen session?
Can you really be sure it's not just some other vulnerability that is letting someone in?
One of the high-profile compromises Slashdot covered in the past involved screen. Screen itself wasn't attacked. But it did provide numerous sessions (including SSH tunnels) that provided access to internal systems through an otherwise pretty hard perimeter.
Screen rocks; I use it all the time. But one really needs to keep in mind the issues involved in using it. Using it to keep open active SSH sessions would be a practical example of one of those issues.
Like many of you, I use OpenSSH to connect to my Slackware Linux boxes remotely
If many of us are connecting to your Slackware boxes, reconnecting is not your largest vulnerability!
(sorry, couldn't resist)
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.
Can you be Even More Awesome?!
That has no bearing on comparing logout/login vs. staying logged in. Yes, the very very first handshake can be bad (there are methods to mitigate, but that's beyond the scope of this discussion), but once you establish that trust, logging out does not break it.
XML is like violence. If it doesn't solve the problem, use more.
Cutting edge cryptanalyst here (PhD in IBE, works for major global security company)
A disclaimer: Conventional crypto is not my game anymore (post-quantum crypto is the way of the future). As any expert will tell you, I am not an expert, but I'll try to shed some light on some aspects of the discussion here.
To begin, we first have to make some reasonable assumptions about the choice of keys in SSH2. There exist known weak primes and weak generators in the DH (Diffie-Hellman) protocol that can be exploited. Assuming the SSH key generator algorithm is smart enough not to choose any known weak primes or generators, we can say the following.
The default OpenSSH implementation uses a 2048-bit prime order field. The security of the DH key exchange protocol is based on the discrete logarithm problem, of which the best known conventional attacks are generally O(sqrt(n)). ie. in laymans terms, roughly equivalent to a keysearch of 2^1024. Quantum computers are another story, but unless you're transferring data that will need to be secure in the order of decades (like you're that important), I doubt you have much to worry about in that regard for a while to come.
AES (the symmetric cipher used in SSH) uses by default 128 bit keys. There are no known attacks on AES better than brute force (ie. on average a keysearch of 2^127, since on average only half the keys will need to be checked before finding your session key). I would say however that there is a far greater chance of someone in the future strongly breaking AES than someone strongly breaking DH. New techniques for attacking symmetric cryptosystems appear all the time (see: Linear cryptanalysis, Differential Cryptanalysis, Impossible Differential Cryptanalysis, Integral Cryptanalysis, Boomerang attacks etc.) whereas DH is based on a very well known and studied number theory problem. Crypto-God Bruce Schneier seems to think AES will be broken in the future, but not enough to allow practical cryptanalysis of traffic.
It's hard to make any definite statements about a comparative analysis of the two schemes, due to the constants (or indeed polynomial terms) of the above complexity statements being unknown. From a purely theoretical standpoint, DH is the weakest link due to it having a better attack than brute force. However, when given this specific set of values to be used, the real-world security comparison is generally seen to be in the favour of DH with 2048 bit prime rather than AES-128. One author suggests Regardless, cycling the session key seems to be free (I can't find any known attacks that use past key exchanges). The SecSH RFC suggests session key cycling after a gigabyte of data, however more often can't hurt.
In short, you don't need to be worried about either DH or AES for a long time to come, but in terms of security, cycling the session key more often than necessary (ie. logging out and back in again) is probably technically more secure. As others have said in this thread however, crypto is very very rarely the weakest link. I'd be looking far more closely at the security of the computers involved than worrying about the crypto being broken.
ssh-agent is its own profound issue: by keeping the key unlocked in a format usable by other shells or software, it makes all your unlocked keys available to anyone who can gain access to the same server as you. This means that I, as an admin, can probably borrow the ssh keys of anyone I've educated in how to use ssh-agent on any of my systems.
Isn't that _convenient_ for me?
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.
I think his question went beyond the question of how secure the session is, even though he did say it.
Which is more secure, to leave a shell opened indefinitely, or to close it?
Unless he's not a normal person, at some point every day, he'll use the restroom. During the work day, he may even go get some food or drinks.
He admitted to using a Windows machine. I won't even comment on how many viruses and trojans are running around, which may compromise his desktop. All it takes is one virus that gives remote access to his desktop that would give someone a clear shot to his servers.
As anyone who's worked in an office long enough would know, once in a great while, you'll get dragged away from your desk, and not lock the console. Maybe someone shoulder surfed your password. Maybe you used the same password for your email account, and it was sniffed in the clear (tisk, tisk, should have used an encrypted method).
Of course, his information may really be worth something. Maybe that root shell will be worth a fortune. What exactly is a dump of the full Bank Of America database worth on the black market? How many fake credit cards can you print up before they reissue every single BoA credit card in circulation? In that case, it would be worth it to visit his home with force. One bump key to the back door, and one silenced shot to the back of the head, and you'd have hours (or days) before you were discovered. As always, there is no security without physical security, and that isn't only the server side of things.
I'm sure someone can name the XKCD issue which points this out the brute force flaw in any security system. A $5 wrench will break any security, if applied properly.
I'll assume his information isn't all that interesting, since he can access remotely without some serious levels of security. I'd believe we're talking about a few low traffic web servers, and a newbie admin impressing himself that he can keep his connection up for days.
Serious? Seriousness is well above my pay grade.
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.