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.
Seriously..
The minor advantage over one or the other is moot.. because unless you've got something of actual importance (in which case it shouldn't be on your home computer) no one is going to go through the bother of trying to break in either way.
If someone wants whats on your computer.. they'll probably just grab you and beat you to a pulp until you give them your password.
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.
SSH doesn't use SSL, and SSHv2 has provisions for rekeying even during a single connection.
rage, rage against the dying of the light
I find using the screen to manage my many simultaneous SSH sessions extremely helpful. This tool is so useful it's on the same level as Adblock is to Firefox. With this tool, the reconnect/connect issue is a moot point.
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 ...
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.
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.
No. The easy, safe, way to protect against lightning strikes is to turn off and unplug the computer so there is no conductive path into it.
Not really, SSL and SSH uses the DH handshake differently. SSL performs all sort of craziness where you select different chipers, sizes and wheter to encrypt at all. SSH does not.
The ask slashdot article is about SSH NOT SSL. Session hijacking has nothing to do with SSH.
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.
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).
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.
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.
Read the big red book "Applied Cryptography: Protocols, Algorithms, and Source Code in C". http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-Source/dp/0471117099/ref=sr_1_1?ie=UTF8&s=books&qid=1265363727&sr=8-1 Highly recommended to anyone who uses public key encryption or needs to implement VPN's, mail encryption or tunnels.
In essence, no it doesn't make any difference. However, if for example you application would communicate short commands often through public key encryption it would be more economical to use persistent connections instead of making new connections all the time. Key generation is Expensive.
Also, in you situation, just use screen.
How in the hell does retarded 'ask slashdots' make the front page, but not my submission of http://itpomminpurkaja.blogspot.com/2010/02/css-anchor-pseudo-class-concerns.html and http://www.fizzl.net/ for which I actually expended some effort to create.
Bot Assisted Blogging
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.