Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Keep SSH Sessions Active, Or Reconnect?

timothy posted more than 4 years ago | from the lock-your-door-or-carry-your-lunch dept.

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

Sorry! There are no comments related to the filter you selected.

screen (3, Informative)

Singularity42 (1658297) | more than 4 years ago | (#31028568)

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

Re:screen (0, Troll)

StudMuffin (167171) | more than 4 years ago | (#31028598)

Just use the program screen if you want to get rooted, you mean. The ONLY time I have ever had a box rooted was when I left screen running.

Re:screen (2, Informative)

MightyMartian (840721) | more than 4 years ago | (#31028618)

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.

Re:screen (5, Insightful)

MrNaz (730548) | more than 4 years ago | (#31028774)

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 (1, Insightful)

Anonymous Coward | more than 4 years ago | (#31028796)

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

Re:screen (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31028902)

screen -r
you are r00ted

Re:screen (2, Informative)

sopssa (1498795) | more than 4 years ago | (#31028906)

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:screen (5, Insightful)

pthisis (27352) | more than 4 years ago | (#31028994)

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 (1)

dgatwood (11270) | more than 4 years ago | (#31029342)

Really, I think it's more a case of balancing the risk of the Windows box getting 0wn3d while the connection to the remote machine is active and somebody taking advantage of that to muck around on your server while you're gone versus the risk of the Windows box getting 0wn3d and somebody capturing the password when you log in and using it to impersonate you later. The former requires a much more sophisticated cracker than the latter, so I'd probably say staying logged in is safer as long as you have pretty airtight physical security.

Re:screen (2, Insightful)

flydpnkrtn (114575) | more than 4 years ago | (#31028642)

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?

Re:screen (4, Informative)

StudMuffin (167171) | more than 4 years ago | (#31028670)

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:screen (2, Informative)

flydpnkrtn (114575) | more than 4 years ago | (#31028770)

"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

Re:screen (0)

Anonymous Coward | more than 4 years ago | (#31029210)

If you're using an obsolete version of Ubuntu/screen, you deserve to be rooted.

Re:screen (1)

blop (71154) | more than 4 years ago | (#31029316)

Shocking vulnerability, you could potentially get rooted just reading some dodgy email in mutt under screen!

It was fixed in October 2006 (couldn't find a POC though) but there must be a lot of people with older versions still...

Re:screen (4, Interesting)

_Sprocket_ (42527) | more than 4 years ago | (#31029248)

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 (5, Funny)

Anonymous Coward | more than 4 years ago | (#31028666)

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 (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31028730)

Me too! Blue car catching on fire that is....

Re:screen (3, Funny)

pookemon (909195) | more than 4 years ago | (#31028888)

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 (2, Funny)

louzerr (97449) | more than 4 years ago | (#31028964)

I've had two cars catch fire ... both blue!!! I think you're on to something ...

Re:screen (1)

pluther (647209) | more than 4 years ago | (#31029068)

I've also had two separate cars catch on fire.

Neither was blue, though.

One was kinda brownish and the other was about half gray and half red. (Primer and rust).

Re:screen (1)

_Sprocket_ (42527) | more than 4 years ago | (#31029262)

You're supposed to paint it blue first. Doesn't anyone RTFM?

Re:screen (2, Funny)

JustOK (667959) | more than 4 years ago | (#31029282)

blue, brown and bi-colored all start with the letter b

Re:screen (0, Redundant)

cheftw (996831) | more than 4 years ago | (#31029308)

I had a car, its colour was WHO CARES?

Sorry, it's late and you're not interesting or on topic.

I realise I'm not either, call it irony.

Re:screen (1)

MrHanky (141717) | more than 4 years ago | (#31028830)

I can't see how you can get rooted by screen except if someone got access to your account and you had a screen session with su root running.

Re:screen (0, Troll)

geekmux (1040042) | more than 4 years ago | (#31029176)

Just use the program screen if you want to get rooted, you mean. The ONLY time I have ever had a box rooted was when I left screen running.

If you could please politely supply the vendor and version of the OS you are running, we would be very grateful. I'm certain I'm not the only one who would like to be running the most secure OS in the known universe...I mean hell, you apparently only have ONE known exploit on your machine. Pretty fucking amazing if you ask me.

Re:screen (4, Informative)

flydpnkrtn (114575) | more than 4 years ago | (#31028616)

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)

You're probably not that special.. (1, Informative)

Anrego (830717) | more than 4 years ago | (#31028578)

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.

Re:You're probably not that special.. (2, Insightful)

Anonymous Coward | more than 4 years ago | (#31028640)

The question of best practices doesn't matter who's important.

Re:You're probably not that special.. (1)

Jorl17 (1716772) | more than 4 years ago | (#31028664)

All you say is true, but more people might be interested in this issue from an abstract point-of-view. See it as a philosophical question: "Is it or not right to do X?"
Of course that, in his case, that's probably overworrying (See, I made a new word!)

Re:You're probably not that special.. (1)

mOdQuArK! (87332) | more than 4 years ago | (#31028684)

because unless you've got something of actual importance (in which case it shouldn't be on your home computer)

You mean, like having a functioning always-connected-to-broadband potential attack platform?

Re:You're probably not that special.. (1)

Anrego (830717) | more than 4 years ago | (#31028868)

You mean, like having a functioning always-connected-to-broadband potential attack platform?

Sitting on the same Internet as thousands unsecured windows machines.

Seriously.. you're argument is just plain silly. No one is going to go to the hassle of covertly breaking Diffe-Hellman or AES for the purpose of setting up a zombie box. If you could do either.. heck if you could do either.. you'd probably make a mint ..

Re:You're probably not that special.. (1)

Annymouse Cowherd (1037080) | more than 4 years ago | (#31029184)

Windows machines behind hardware firewalls, unfortunately.

Re:You're probably not that special.. (1, Insightful)

Cassini2 (956052) | more than 4 years ago | (#31028738)

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:You're probably not that special.. (1)

_Sprocket_ (42527) | more than 4 years ago | (#31029302)

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.

Your value as a victim is often directly proportional to the ease with which you are attacked. Even assumed difficult attacks become easy if they can be automated.

better question: (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#31028582)

where's the digg button? I see facebook and twitter, but no digg :(

Re:better question: (0)

Anonymous Coward | more than 4 years ago | (#31028680)

All the cool kids are using Reddit nowadays, Digg has dugg its own grave.

Wat (4, Informative)

sakdoctor (1087155) | more than 4 years ago | (#31028584)

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:Wat (4, Informative)

xZgf6xHx2uhoAj9D (1160707) | more than 4 years ago | (#31028818)

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 (2, Interesting)

Anthony Liguori (820979) | more than 4 years ago | (#31028960)

The short answer is: Whatever.

It's a little more nuanced than that. To the extent that a long term session is more predictable than a short term session (or vice versa), it may matter. See Timing Analysis of Keystrokes and Timing Attacks on SSH [berkeley.edu] .

Re:Wat (5, Informative)

hunteke (1172571) | more than 4 years ago | (#31028970)

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.

Anonymous Coward (0)

Anonymous Coward | more than 4 years ago | (#31028586)

You kind-of answered your own question. Rebuilding the link over and over is of course more open to being seen/sniffed than an estabilished tunnel.

Re:Anonymous Coward (2, Informative)

dougmc (70836) | more than 4 years ago | (#31028706)

Well, yes and no.

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:Anonymous Coward (2, Interesting)

mysidia (191772) | more than 4 years ago | (#31028816)

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.

Re:Anonymous Coward (1)

louzerr (97449) | more than 4 years ago | (#31028984)

Also, someone sniffing the network can quickly see those machines you have accounts for with a quick glance. If a curious hacker was inside your network, you would be an "interesting" target.

One-time pad (0)

Anonymous Coward | more than 4 years ago | (#31028590)

Just modify a telnet server to use one-time pads and you don'te have to worry about handshakes being sniffed. Just carry around 8GB of one-time pad around on a CF card (cause SD has DRM and is therefore evil)

Re:One-time pad (4, Interesting)

Sloppy (14984) | more than 4 years ago | (#31029002)

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.

Re:One-time pad (3, Interesting)

fbjon (692006) | more than 4 years ago | (#31029182)

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

Re:One-time pad (0)

pclminion (145572) | more than 4 years ago | (#31029334)

Not really hard. Buy two 2 TB drives, fill them with the same, cryptographically strong random data. Travel with both drives to one secure endpoint, deposit one drive there. Return to the other secure endpoint, deposit the other drive there. The drives are never out of your possession until they are in the hands of the other trusted party. Depending on what kind of crap you are encrypting, 2 TB is plenty of pad to last for quite some time.

If physically traveling to the endpoints with the pads is cost-prohibitive, then the data you are protecting probably isn't important enough for OTP anyway.

Re:One-time pad (1)

DamnStupidElf (649844) | more than 4 years ago | (#31029270)

Your biggest problem with a OTP is authentication. How do you know an attacker didn't guess that the first thing you run when you log in is "mail", and xored ("mail" xor "rm *") against the ciphertext stream? If you need to trust a cryptographic secure message digest for authentication, you might as well use a plain old cipher like AES for encryption.

Re:One-time pad (0)

Anonymous Coward | more than 4 years ago | (#31029324)

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.

Unfortunately, OTP while theoretically perfect has serious practical weaknesses that go beyond the simple inconvenience of having to carry around lots of randomized data. The key practical difficulties essentially are that the OTP must be truly random and most importantly must never ever be reused. It is very difficult to create an encryption system easy to use and transparent to the user using OTP, there are simply too many possible ways for the user to unintentionally make a blunder.

As wikipedia will tell you, historically even spy agencies were not able to keep the above rules and came unstuck when they reused pads, or were not able to randomize the OTP sufficiently.

Re:One-time pad (2, Insightful)

_Sprocket_ (42527) | more than 4 years ago | (#31029328)

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

necama (10131) | more than 4 years ago | (#31029332)

So let me get this straight. You want everybody in the world to carry around synchronized OTPs for every computer they could possibly interact with securely, and all servers to store enough OTPs for all their users, and then, as the OTP protocol requires, throw out the pieces of the pad you've already used? The whole point of a OTP is to deny any sort of pattern formation in the encrypted data due to patterns present in the key and the encrypted stream by making sure there is absolutely no correlation between the two.

Then there is the distribution question. How do you make sure both sides of the OTP are the exact same? Without using quantum encryption protocols (sorry, I don't remember the current distance restrictions on these), there is no known secure way to distribute OTPs short of meeting in person with the person you want to share a pad with, and then making two exact copies of the data.

I'll take Diffie-Hellman for now. If we reach a point where quantum encryption becomes ubiquitous (I'm not holding my breath), then we can talk about OTP as a serious option.

Sniffing? (1)

Microlith (54737) | more than 4 years ago | (#31028610)

If you're worried that the possibility someone is going to perform an MITM attack on you is greater than infinitesimal, then there are far more important things for you to worry about than whether or not to leave your SSH sessions connected.

I'd be more concerned about security on the end points, particularly on the Windows XP machine. Not hard, but far more pressing than someone finding you interesting enough to insert themselves into your communication.

Unless you -are-, in which case you should manually perform the key exchange and never actually send the passwords in the first place.

Re:Sniffing? (4, Interesting)

ettlz (639203) | more than 4 years ago | (#31028802)

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

look into shwatchr and screen (1)

loVolt (664437) | more than 4 years ago | (#31028612)

I like screen and shwatchr then you can reconnect to your session and if it's from a unauthorized host it gets the boot!

Re:look into shwatchr and screen (1)

stefanlasiewski (63134) | more than 4 years ago | (#31028746)

Hrm, it appears that the author of shwatchr [cipherdyne.com] hasn't updated it since 2001.

I do like Mike Rash ( Cipherdyne.com ) and have used some of his software (psad will analyze my firewall logs using Snort fingerprints, to help determine the type of attack).

But I would hesitate to use any software which has not been updated in nine years.

Always mitigate against the most likely risk (5, Informative)

pthisis (27352) | more than 4 years ago | (#31028624)

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 (0)

Anonymous Coward | more than 4 years ago | (#31028918)

Yes, it's good advice to stay connected at all times. After all, what if someone powered down your server, installed some hardware bug, then powered it back up?

Re:Always mitigate against the most likely risk (4, Insightful)

massysett (910130) | more than 4 years ago | (#31029000)

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 (3, Informative)

fm6 (162816) | more than 4 years ago | (#31029082)

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.

Simple (1)

Kjella (173770) | more than 4 years ago | (#31028626)

....if one can be broken, probably the other one too. The chance that the frequency of which you connect matters is <0.001% in my opinion. Either it's secure or it isn't, and either way slashdot won't be able to answer that.

Neither (3, Informative)

nacturation (646836) | more than 4 years ago | (#31028632)

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.

Reconnect. (-1)

strredwolf (532) | more than 4 years ago | (#31028638)

Seriously, reconnect. The keys used for the encryption will change, and it's multiply keyed to boot. Check the discussion on SSL (which SSH uses) on Steve Gibson's Security Now podcast. http://twit.tv/sn [twit.tv]

Re:Reconnect. (4, Informative)

pthisis (27352) | more than 4 years ago | (#31028692)

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

Re:Reconnect. (1)

fusiongyro (55524) | more than 4 years ago | (#31028938)

You're right, but they do both use Diffie-Hellman for key exchange, so the security implications of setting up the connection are similar.

Re:Reconnect. (1, Informative)

Anonymous Coward | more than 4 years ago | (#31029212)

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.

Catch 22 (2, Interesting)

SnoopJeDi (859765) | more than 4 years ago | (#31028656)

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.

Re:Catch 22 (1)

musicalmicah (1532521) | more than 4 years ago | (#31029292)

That sounds a bit absolutist to me. The question was not "which is secure" but rather "which is more secure." One can argue that my home is not secure because locks are easily compromised by someone who knows what they're doing, and one would be right. However, my home is still more secure when I lock the door than when I don't.

Probably safe (1)

cl!p (902247) | more than 4 years ago | (#31028662)

If the servers and clients are physically safe/locked that is. SSH renegotiates the encryption keys by default when nessesary. So even if an adversary tries to break your keys, he would have to sart over pretty soon.

all of the above (1)

larry bagina (561269) | more than 4 years ago | (#31028676)

reconnect as needed, but tunnel your ssh over an ssh session which is always active.

Re:all of the above (3, Funny)

moonbender (547943) | more than 4 years ago | (#31028718)

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

Or... (2, Funny)

DRAGONWEEZEL (125809) | more than 4 years ago | (#31028876)

When you cross the two encryption streams you may get total protonic reversal, or you may get 1 REALLY POWERFUL STREAM.

Re:all of the above (1)

drachenstern (160456) | more than 4 years ago | (#31028890)

So what you`re saying is ... don`t cross the streams?

Ah, the feared ROT13 cypher? (1, Funny)

rsborg (111459) | more than 4 years ago | (#31028974)

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

Yes, you are correct, but you may want to upgrade from ROT-13 to ROT-26.

Depends... (2, Funny)

Monkeedude1212 (1560403) | more than 4 years ago | (#31028688)

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.

gnu screen (1, Informative)

laktech (998064) | more than 4 years ago | (#31028694)

I find using the screen [gnu.org] 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.

Re:gnu screen (2, Interesting)

mirix (1649853) | more than 4 years ago | (#31028820)

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 [sourceforge.net]

Neither is "more" secure (3, Insightful)

Rantastic (583764) | more than 4 years ago | (#31028696)

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:Neither is "more" secure (0)

Anonymous Coward | more than 4 years ago | (#31028834)

You are contradicting yourself. You give useful advise, and at the same time you say that asking on Slashdot is bad. Or do you mean that your third line is to mislead the submitter?

One Way to Prevent Session Hijacking (0)

blitzkrieg3 (995849) | more than 4 years ago | (#31028702)

Intuitively, longer sessions can lead to session hijacking [codinghorror.com] . This implies that it's safer to reconnect. I'm sure ssh has some way to prevent session hijacking though.

Re:One Way to Prevent Session Hijacking (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31029038)

Dude, I do not think this means what you think it means...

Re:One Way to Prevent Session Hijacking (3, Informative)

Vairon (17314) | more than 4 years ago | (#31029226)

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

You say either, I say either... (1)

slushdork (566514) | more than 4 years ago | (#31028766)

It doesn't matter either way. Barring some unknown bug in the SSH implementations (or, even more unlikely, the underlying SSH 2 protocol, or, yet even more unlikely, the under-underlying encryption mechanisms), you can stay logged in or keep re-loging in - both methods should provide no information to an attacker.

Even if there were unknown bugs, you still wouldn't be able to decide: staying logged in gives the attacker more encrypted material to analyze from the same session & keys. Re-loging in every 10 minutes gives them more handshake data.

By the way, I hope that hosts.allow is not the only way you're protecting your servers from the "big bad internet"...

Re:You say either, I say either... (1)

mindstrm (20013) | more than 4 years ago | (#31029152)

assuming the ssh session is the target - they don't need to break the encryption, they only need to get access to the windows box with putty running on it - which is a heck of a lot more likely than cracking SSH.

How safe is your box? (4, Informative)

gmuslera (3436) | more than 4 years ago | (#31028804)

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 (4, Informative)

phantomcircuit (938963) | more than 4 years ago | (#31028832)

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.

Depends where you're connecting from (1)

bram (490) | more than 4 years ago | (#31028870)

If you're connecting with putty it implies starting of from a risky platform.

Otherwise it wouldn't make a big difference.
With enough resources session keys can probably be replayed either way.

I have a solution (1, Insightful)

signingis (158683) | more than 4 years ago | (#31028874)

Go outside.

Re:I have a solution (0, Offtopic)

macintard (1270416) | more than 4 years ago | (#31028928)

Agreed. Can we find better questions to submit?

Don't leave your computer turned on. (2, Insightful)

Medievalist (16032) | more than 4 years ago | (#31028910)

"Is it safer to log out of an SSH session, and re-establish it later, or just keep the connection open?

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.

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

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:Don't leave your computer turned on. (2, Informative)

gregben (844056) | more than 4 years ago | (#31029110)

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:Don't leave your computer turned on. (1)

JustNiz (692889) | more than 4 years ago | (#31029346)

I also bury my computer in the yard after every time I'm done using it, so that its safe from nukular war.

Re:Don't leave your computer turned on. (1)

zippthorne (748122) | more than 4 years ago | (#31029314)

You can just click through that? There's an easier way than going into .ssh/known_keys and deleting the offending line?

I thought it was like that to force you to think about why the host you're connecting with might be presenting you with a new key...

keep alive of course, just in case you get fired (0)

Anonymous Coward | more than 4 years ago | (#31029028)

keep alive of course, just in case you get fired

they might change passwords, regenerate keys, restarts sshd, but by default sshd does not drop existing connections ;-)

so, when when you get home, all depressed, you sit down in front of your computer, the screen comes on, and you go "hey, I am still logged in"

then with a smirk on your face, you can still go to work

next few days when they call you that you are hired back, send them your consulting rate (3-4X your regular salary)

dont you read BOFH to know this?

In your situation (4, Insightful)

mindstrm (20013) | more than 4 years ago | (#31029144)

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.

Boring... (2, Funny)

brundlefly (189430) | more than 4 years ago | (#31029178)

This is exactly the sort of question that Stack Overflow was created for....

Restarting makes traffic analysis a little easier. (4, Interesting)

dweller_below (136040) | more than 4 years ago | (#31029244)

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

The vulnerability is in the endpoints (0)

Anonymous Coward | more than 4 years ago | (#31029280)

The tunnel can be considered safe, regardless of whether you reconnect often, or leave it connected. The attack target worth considering in this case is the tunnel endpoints. Consider that your box is owned and the remote box is not. The remote box can only be tampered with while the tunnel is established, so leaving the ssh session active leaves you more vulnerable. (This is only valid if establishing the tunnel requires three-factor-authentication, such that the attacker can't reestablish the tunnel at will.)

Like many of us ... (5, Funny)

Lemming Mark (849014) | more than 4 years ago | (#31029298)

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)

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?