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."
screen (Score:3, Informative)
Just use the program, "screen", if you want to resume your sessions.
You're probably not that special.. (Score:1, Informative)
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.
Wat (Score:5, Informative)
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 [wikipedia.org]
Re:screen (Score:5, Informative)
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 (Score:3, Informative)
I actually use screen a lot, particularly when I'm doing big compiles or other operations that are going to be going on for a while. Particularly when I'm working from home, I've been nailed by way too many spurious disconnects. Screen is an awesome little program. I use it when I'm coding in the shell, I can flip between screens a lot faster than I can through any GUI.
Always mitigate against the most likely risk (Score:5, Informative)
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).
Neither (Score:4, Informative)
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:screen (Score:5, Informative)
http://www.ubuntu.com/usn/usn-370-1 [ubuntu.com]
Burned by that. Prolly fixed now, but that doesn't mean I am eager to resume :D Call me old fashioned.
Re:Reconnect. (Score:5, Informative)
SSH doesn't use SSL, and SSHv2 has provisions for rekeying even during a single connection.
gnu screen (Score:1, Informative)
Re:Anonymous Coward (Score:3, Informative)
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 ...
Re:screen (Score:3, Informative)
"cstone and Rich Felker discovered a programming error in the UTF8 string handling code of "screen" leading to a denial of service. If a crafted string was displayed within a screen session, screen would crash or possibly execute arbitrary code."
Wow.... ouch. Especially on a shared host with random other people you don't know...
OpenVZ VPS's for the win! It's your own personal "box" effectively
How safe is your box? (Score:5, Informative)
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.
Re:Wat (Score:5, Informative)
Key Fingerprint (Score:5, Informative)
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:screen (Score:3, Informative)
Exactly.
The only thing we can say here is that if your computer is physically secured (you can log out to login screen and leave the sessions running, and encrypt your hdds), it doesn't matter if you leave your session running or not. Your ISP can't "sniff that handshaking" and go on without you getting a security warning. If you do, you just wont accept the connection and try to solve what's going on. Just remember to log out after leaving from computer.
If NSA or some other organization had a way to break into your SSH session and they cared to use it against you (with the risk of that info leaking), then you have much larger problems than worrying about if you should leave ssh sessions open or reconnect.
Re:Wat (Score:5, Informative)
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:
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.
Re:Always mitigate against the most likely risk (Score:4, Informative)
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.
Re:Don't leave your computer turned on. (Score:2, Informative)
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.
Re:Reconnect. (Score:1, Informative)
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.
Re:One Way to Prevent Session Hijacking (Score:4, Informative)
The ask slashdot article is about SSH NOT SSL. Session hijacking has nothing to do with SSH.
Re:screen (Score:3, Informative)
Re:Wat (Score:3, Informative)
ssh-keygen -l -f
Re:screen (Score:5, Informative)
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 (Score:2, Informative)
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:
Re:Better to disconnect (Score:2, Informative)
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 [3ami.com], 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.
Re:Better to disconnect (Score:2, Informative)
Addendum: embarrassed that I mentioned UltraVNC without also mentioning Timbuktu [wikipedia.org] 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).
Re:Wat (Score:3, Informative)
The solution to the first-time key exchange is SSHFP + DNSSEC [roysdon.net].
Re:OK, I grant that you did say "theoretically", b (Score:2, Informative)
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.
Re:screen (Score:5, Informative)
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.
Solving the wrong problem. (Score:3, Informative)
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.
Re:screen (Score:1, Informative)
I'm only posting anonymously because I moderated already. But I've thought about this problem also, and it comes down to user education, including admin superusers. One rule we have at our company is you su to root first before using the root user in a screen session. This way you have to be root in order to attach to the session, meaning that you already have the privilege of running as root.
You can also add a session password to screen for added security so even other members of root cannot attach.
In other words, if you have to keep root open in a screen su to root first before using screen.
Re:screen (Score:1, Informative)
Try tmux [sourceforge.net] instead of screen. I've found it to be more robust and intuitive, probably by virtue of not being GNU.
Edumacation (Score:2, Informative)
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 [amazon.com] 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 [blogspot.com] and http://www.fizzl.net/ [fizzl.net] for which I actually expended some effort to create.
Re:Man-in-the-middle? (Score:3, Informative)
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.