Keep SSH Sessions Active, Or Reconnect? 307
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."
Re:You're probably not that special.. (Score:2, Insightful)
Re:screen (Score:3, Insightful)
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?
Neither is "more" secure (Score:4, Insightful)
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.
Re:You're probably not that special.. (Score:2, Insightful)
People constantly scan internet ports to find something open and worth hacking.
Linux servers are useful as command and control servers for bot-nets.
Re:screen (Score:5, Insightful)
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.
Re:screen (Score:1, Insightful)
That is, unless you work for the military of a major world power and are known to be transmitting valuable intel.
In which case you pretty much go to jail for storing that stuff on your home computer
I have a solution (Score:1, Insightful)
Go outside.
Don't leave your computer turned on. (Score:3, Insightful)
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.
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).
Re:screen (Score:5, Insightful)
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).
Re:Always mitigate against the most likely risk (Score:5, Insightful)
Breaking the crypto is almost assuredly not the weakest point in your connection. I'd stay connected,
You're right about the crypto not being a concern, but I think the bigger danger is that he gets up to go to the bathroom or printer or something and he forgets to lock the client machine. Cert change alerts are hard to ignore, at least with OpenSSH. Logout.
In your situation (Score:4, Insightful)
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.
Re:One-time pad (Score:3, Insightful)
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.
Or carry a token [wikipedia.org].
Re:Always mitigate against the most likely risk (Score:3, Insightful)
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.
Buffer overflow? Underflow? Stack smashing?
None of those exploit vectors require even 'user interaction' let alone could be called 'user error'
I would have to venture a guess that, while probably not anywhere close to the share true user error has, such attack vectors still do have some share none the less.
Re:screen (Score:1, Insightful)
That is very fascinating. Can you give us some more details about what happened?
Was it a shared host with multiple users?
How did the evil string get displayed?
Did just your user account get compromised or was it truly a "root"ing?
However... (Score:5, Insightful)
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.
Re:One-time pad (Score:4, Insightful)
Great, now you have something that will work for 5% of the cases in which people need to remotely connect.
I never suggested that this is a general crypto solution for the masses. I am pointing out that if you think you do need to security offered by an OTP system, it's not really that hard to communicate the pads securely. If I can't afford a $1000 plane ticket to deliver the pad in person, chances are my data isn't important enough to need that level of security in the first place.
Re:screen (Score:5, Insightful)
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.
Re:screen (Score:5, Insightful)
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?
Re:screen (Score:3, Insightful)
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.
If anyone has the capability, it's the NSA. They could use it routinely without anyone else knowing, they're good enough at keeping secrets that no one would know until long after it mattered. These are the people who discovered differential cryptanalysis and didn't let the cat out of the bag until 20 some odd years later when academia discovered it.
LK
tag: youarentthatimportant - WTF? (Score:5, Insightful)
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.
Re:Neither is "more" secure (Score:3, Insightful)
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 :)
There is no answer.. (Score:2, Insightful)
Re:screen (Score:2, Insightful)
RTFM.
That's why you set a screen password. Control + A, : password ENTER
The attach cannot proceed without typing the password. The password cannot be changed (for an already running session) without attaching first.
From the screen man page:
So what does screen actually do to protect the programs inside? I mean with the privileges to attach the screen and not knowing the pw, you usually also have the privileges to debug the bastard and skip the pw check altogether.
More info? (Score:3, Insightful)
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.
Re:You're probably not that special.. (Score:3, Insightful)
Indeed. Speaking from a military standpont (I was in communications in the Canadian Forces, Army), the longer a communications link remains open, the more chance there is that somebody will notice it. Now, the costs are a *lot* higher when you're talking about battlefield communications and the potential for enemy artillery, but the principle remains the same: if you keep an encrypted communications link open 24/7, then the chance that somebody will take notice and try to do something with it are significantly increased. It doesn't matter that you're probably not a valuable target, or that you may not necessarily lose much if your connection is hit, the chance of it happening increases with every minute you spend connected. When talking about SSH, yes, it's encrypted, but there's nothing to stop them from sitting there and logging all of the traffic that passes, and just waiting for the next time the SSH handshake happens.
Best practice is to open the link, do what you need to do, and close the link.
Re:screen (Score:3, Insightful)
I would ask, why would you even allow password-based logins to your server?
Because requiring key files presents a barrier to the ability to do work, and that penalty is far greater than the small risk of being hacked in a manner that's caused by allowing password-based logins.
It's not unheard of for things to go wonky when a key employee's on vacation or over at a friend's house or wherever, and the benefit we get from having them be able to download putty, log in, and fix things is a lot higher than the tradeoff.
In a security-focused sysadmin's world it'd be nice to tell them they should carry a keyfile with them everywhere, but in the real world that doesn't really work out all the time.