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."

Comments

screen

[Singularity42]

Just use the program, "screen", if you want to resume your sessions.

Re:screen

[flydpnkrtn]

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

[Anonymous Coward]

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.

Re:screen

[StudMuffin]

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.

Re:screen

[MrNaz]

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

[pookemon]

The only car I have ever seen on fire (in real life as opposed to on TV) was a Porsche - and it was blue.

And I currently have two laptops that I amd repairing - both of them have buggered screens.

Oh, and then there's the "Blue Screen of Death" - though I've only seen one PC burst into flames after a BSOD, so that was probably a coincidence...

Re:screen

[pthisis]

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:screen

[_Sprocket_]

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.

Re:screen

[zippthorne]

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

[Anonymous Coward]

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

[Antique Geekmeister]

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

[JWSmythe]

    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.

Re:screen

[Antique Geekmeister]

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.

Wat

[sakdoctor]

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

Re:Wat

[xZgf6xHx2uhoAj9D]

More to the point (since basic Diffie-Hellman is vulnerable to man-in-the-middle attacks), if you already have the "fingerprint" stored for your home machine, that really can't be faked, so you're safe. If you're not storing the "fingerprint" (why not?) then, well, why would anyone do that?

Re:Wat

[hunteke]

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:

The authenticity of host 'ssh.example.com (123.234.123.234)' can't be established.
RSA key fingerprint is 96:21:c3:32:3d:cc:18:d5:53:6a:d4:0d:0d:73:c6:1a.
Are you sure you want to continue connecting (yes/no)?

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.

Always mitigate against the most likely risk

[pthisis]

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).

Re:Always mitigate against the most likely risk

[massysett]

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.

Re:Always mitigate against the most likely risk

[fm6]

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.

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.

Neither

[nacturation]

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:Reconnect.

[pthisis]

SSH doesn't use SSL, and SSHv2 has provisions for rekeying even during a single connection.

Neither is "more" secure

[Rantastic]

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:all of the above

[moonbender]

Are you crazy? Obviously the two encryptions would cancel out each other!

Re:Sniffing?

[ettlz]

If you're worried that the possibility someone is going to perform an MITM attack on you is greater than infinitesimal

...or the DNS cache gets poisoned, as I once saw. (Thankfully, SSH does a reverse lookup as well and checks the result matches the input, and bails if they don't.)

How safe is your box?

[gmuslera]

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.

Key Fingerprint

[phantomcircuit]

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:One-time pad

[Sloppy]

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.

In your situation

[mindstrm]

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

[fbjon]

It's not the carrying around that's burdensome, it's getting the OTP data to wherever you're connecting.

Re:One Way to Prevent Session Hijacking

[Vairon]

The ask slashdot article is about SSH NOT SSL. Session hijacking has nothing to do with SSH.

Restarting makes traffic analysis a little easier.

[dweller_below]

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 us ...

[Lemming Mark]

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)

However...

[Junta]

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

[pclminion]

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.

tag: youarentthatimportant - WTF?

[wvmarle]

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.