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."
Just use the program, "screen", if you want to resume your sessions.
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
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
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.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
The question of best practices doesn't matter who's important.
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.
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.
SSH doesn't use SSL, and SSHv2 has provisions for rekeying even during a single connection.
rage, rage against the dying of the light
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.
Ask Slashdot: Where bad ideas meet poor googling skills.
It gives the hacker more chances to sniff the connection, but less time to decrypt whatever was sniffed during the beginning of a connection and use it to take over the connection.
It could go either way, depending on whatever vulnerabilities may be found in OpenSSH in the future (or are already known, but not public knowledge.)
Personally, I'd think that going for more, shorter lasting connections would be safer than fewer, longer lasting ones, simply because if they can figure out your password from the key exchange, they can probably do it every time, so it doesn't matter if it's one or many times -- they go it. Of course, this assumes a future vulnerability ...
Are you crazy? Obviously the two encryptions would cancel out each other!
Switch back to Slashdot's D1 system.
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.
What if the vulnerability is a cryptanlytic one in the protocol used by OpenSSH for the key negotiation?
Something like: 2^10 initial key exchanges, reduces the search space for an attacker trying to guess the key
Or certain nonce values turn out to be vulnerable, but not others.
Then more session setups helps the hacker to improve their chances of guessing.
dtach is tiny screen-like app, well, it does just the detach portion of it. Handy if you're running it on something pathetic (hacked router, fe.), and don't need all of GNU screen's bells and whistles.
dtach
Sent from my PDP-11
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.
When you cross the two encryption streams you may get total protonic reversal, or you may get 1 REALLY POWERFUL STREAM.
How much is your data worth? Back it up now.
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.
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).
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.
This is exactly the sort of question that Stack Overflow was created for....
It's not the carrying around that's burdensome, it's getting the OTP data to wherever you're connecting.
True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
The ask slashdot article is about SSH NOT SSL. Session hijacking has nothing to do with SSH.
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
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)
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.
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.
The short of it is you need to be the only Administrator of your workstation, in order to really have a connection to the Unix servers that you can verify the security of. You are most "secure" with a standalone workstation, having Windows Firewall enabled, no exceptions enabled, no domain membership, forceGuest set to on, and passwords required for all local access.
If your organization requires security of the servers, then ensuring no untrusted admin has the technical ability to screw with workstations is critical.
Just because a naive Windows admin doesn't have a simple way of shadowing your session, doesn't mean it is at all hard.
One group policy setting to deploy "compliance software" such as 3AMI/MAS Employee Monitoring Software, with keylogging enabled, and.. suddenly your SSH sessions and passwords aren't so secure... Oh, that's just the legal route. Of course, "trojans" or some $5 keylogger can be deployed too, from a system management console, and configured via enforced registry settings.
If you have software installed by someone else, OR someone else has a valid login to your workstation, OR your computer is a member of a Windows domain, then someone else can run software on your computer, and they can also change the configuration to enable them to shadow your session.
And yes, most shrink-wrapped management software provide a way to do this. Typically, the technology used is VNC, TightVNC, or UltraVNC.
There are also some commercial software (remote access) products that do this.
Most management software allow the running of arbitrary remote programs. It is trivial to deploy registry settings and software via group policy or remote IPC access, from a domain computer.
Tools included with Windows Server and available through SYSINTERNALs allow this without buying any management suite.
But DameWare, Hyena SystemTools, Purgos, ScriptLogic, LANRev, ZENWorks, IBM Director, all provide point-and-click interfaces to do this sort of thing.
The management software itself may provide a simple "one-click link" to quietly shadow your session.
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.
Addendum: embarrassed that I mentioned UltraVNC without also mentioning Timbuktu can be made to do this.
VNC normally displays a little icon in the taskbar, but a simple registry setting pushed via login script or group policy can hide it.
It can also be easily hidden in task manager/process viewer, through other methods, I won't mention, because they are easily abusable tricks I don't wish to encourage, not documented anywhere, and relatively unknown to most developers and to the community. But also not hard to figure out: so, you don't need other people having access to your computer if you want anything close to a security guarantee, you must fully and properly administer and secure your workstations yourself (or have someone trusted due that, without lending access to a large population of admins via domain or central management).
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.
They don't have to crack DHE in general, all they need to crack is diffie-hellman-group1-sha1.
Since a fixed DH group is used, this could be attacked through precomputing many values for the discrete logarithm.
If the key negotiation happens to fall into one of the precomputed values, then that session is in trouble.
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.
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.
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.
Your concerns are irrelevant, here. SSH fingerprints make man-in-the-middle attacks effectively impossible, as long as the user doesn't habitually ignore the (rather obvious) messages and errors when keys change. I don't know about you, but I have a hard time glossing over a message like "KEY CHANGED--SOMEBODY COULD BE TRYING TO BREAK IN!" and the subsequent error.
The initial "unknown key" error message isn't quite as loud, and lots of people don't bother validating key fingerprints, but that doesn't matter because initial connections aren't the scenario we're discussing, here. Whether the use decides to make new connections or keep existing ones open, he's already approved the key fingerprints during a previous connection.
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.