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.
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: (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.
Re:screen (Score:5, Insightful)
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: (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
Re:screen (Score:5, Insightful)
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: (Score:2)
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
Re: (Score:2)
The thing is, he will eventually have to login again. While my connection is really stable, sometimes ssh session just breaks or you have to reboot your windows. Or your connection could break for a few seconds and that already breaks it.
You're looking at max 2-3 weeks session time anyway.
There is no better way. You have to keep sure you are secure to both.
Re: (Score:3, Informative)
Re: (Score:2)
Assuming the crypto is strong enough, and I think it is, the chances of getting hacked amount to "user error".
What kinds of user errors could happen?
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
RSA key fingerprint is 24:ba:36:a4:4b:11:59:e8:ec:dd:75:15:f2:2e:74:dc.
Are you sure you want to continue connecting (yes/no)?
If you occasionally get that, legitimately because you lose your key fingerprint hashes, you might fall for a man-in-the-middle attack. If y
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:5, Insightful)
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 (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.
Re: (Score:3, Insightful)
I would ask, why would you even allow password-based logins to your server?
Because requiring key files presents a barrier to the ability to do work, and that penalty is far greater than the small risk of being hacked in a manner that's caused by allowing password-based logins.
It's not unheard of for things to go wonky when a key employee's on vacation or over at a friend's house or wherever, and the benefit we get from having them be able to download putty, log in, and fix things is a lot higher than the tr
Re:screen (Score:5, Insightful)
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: (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
Re: (Score:3, Insightful)
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.
If anyone has the capability, it's the NSA. They could use it routinely without anyone else knowing, they're good enough at keeping secrets that no one would know until long after it mattered. These are the people who discovered differential crypt
Re:screen (Score:5, Interesting)
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: (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: (Score:3, Insightful)
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 (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: (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
Re:screen (Score:5, Interesting)
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 (Score:5, Funny)
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: (Score:3, Funny)
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: (Score:2, Funny)
I've had two cars catch fire ... both blue!!! I think you're on to something ...
Re: (Score:2)
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: (Score:2)
You're supposed to paint it blue first. Doesn't anyone RTFM?
Re: (Score:3, Funny)
blue, brown and bi-colored all start with the letter b
Re: (Score:2)
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.
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:Wat (Score:5, Informative)
Re: (Score:3, Interesting)
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 (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: (Score:3, Informative)
ssh-keygen -l -f
However... (Score:5, Insightful)
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: (Score:3, Funny)
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
So what if this administrator you're having such a secure conversation with has someone holding a gun to his head! Guess you're not so secure now, huh?
Re: (Score:3, Informative)
The solution to the first-time key exchange is SSHFP + DNSSEC [roysdon.net].
Re: (Score:2)
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).
Re:Always mitigate against the most likely risk (Score:5, Insightful)
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 (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: (Score:3, Insightful)
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.
Buffer overflow? Underflow? Stack smashing?
None of those exploit vectors require even 'user interaction' let alone could be called 'user error'
I would have to venture a guess that, while probably not anywhere close to the share true user error has, such attack vectors still do have some share none the less.
Re: (Score:2)
With most SSH implementations, you can't ignore a cert change alert. It's more of a fatal error, at least with every SSH client I've ever used.
When I reinstall a machine (or regenerate a cert due to, say, a stupid upstream bug), it spits out a big nasty error and will not continue until I remove the offending key from known_hosts.
Simple (Score:2)
....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 (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.
Catch 22 (Score:3, Interesting)
Re: (Score:2)
I don't think that's the case. I'm pretty sure you can transport the host machine fingerprint to the client, and the public key to the server, and have it impossible to crack the connection without breaking the crypto.
IANACE (crypto expert) but I think the only avenue for MITM is on the *first* connection to the host, where you need to trust that the link is secure enough to not modify the fingerprint. If you don't need to trust that... I think you're safe.
Depends... (Score:2, Funny)
Neither is "more" secure (Score:4, Insightful)
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: (Score:3, Insightful)
If I told you that it is far more secure to leave your connection open all day, would you take my word for it?
He didn't ask you, he asked Slashdot. If everyone reputable tells him the same thing, he can probably believe it. If he had time to become a security expert, he probably would have. There are of course no certainties in life, but generally speaking, you can trust the experts most of the time. Amusingly enough, many of the experts seem to have plenty of time to read Slashdot, and even post occasionally :)
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.
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.
Don't leave your computer turned on. (Score:3, Insightful)
It's safer to log out and re-establish. UNLESS you are subverting host key verification - just clicking past the big warning sign that OpenSSH throws up when it sees an unknown host key - in which case you certainly can get MITM'd. Keep copies of your public (not private!) host keys on a thumb drive for use the first time you connect from an outside box.
I believe the "handshake" is a diffie-hellman key exchange. It can't be sniffed and cracked in realtime. On the other claw, I suppose it's theoretically possible that if you leave the connection open long enough, a determined attacker with titanic resources can brute your session key. In reality, I personally don't think that will ever happen to you, it'd be cheaper for anyone with those kind of resources to use the $5 wrench upside your head method. [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: (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: (Score:2)
I also bury my computer in the yard after every time I'm done using it, so that its safe from nukular war.
Re: (Score:2)
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...
In your situation (Score:4, Insightful)
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... (Score:3, Funny)
This is exactly the sort of question that Stack Overflow was created for....
Restarting makes traffic analysis a little easier. (Score:5, Interesting)
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
Re: (Score:2)
Here is a better idea, do not open ssh to the world. Make them vpn in first, then ssh. Security in layers.
Re: (Score:2)
That's a maddeningly recursive solution...
Like many of us ... (Score:5, Funny)
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)
Better to disconnect (Score:2)
Unless you lock your desktop every single time you get up and walk away from your desk, it's better to generally disconnect, because you lessen the (admittedly very small odds) that someone else will simply walk up to your workstation, and either out of malice, curiosity or just mistake (they think you are logged in someplace it's ok for them to poke around), they end up accessing your remote session.
It may also look suspicious to sysadmins that you keep sessions alive for so long.
Is it possible for a Windo
Re: (Score:2)
Is it possible for a Windows admin to poke around your desktop, remotely, without your knowledge? I believe they normally have to make a request that you accept before you hand over control of your desktop to a Windows admin, but I don't know if Windows (or other corporate monitoring software) allows this to happen without your knowledge.
Remote desktop takes control of the session, so you're locked out, they don't access your session. Now obviously some monitoring software out there is going to have a "stealth" mode, but that has nothing to do with Windows, it could happen on any OS.
Re: (Score:2)
I didn't really mean remote desktop; I meant more "session sharing", though my point is not the standard session sharing someone will request if you're asking an admin for Windows help.
Yes, a stealth program installed by your employer could happen on any OS. My point is not that this is a Windows problem, but that such software has more opportunity to observe what you've been doing remotely if you leave sessions open all the time.
Very simple consideration (Score:2)
If you log in typing in a password, it might be easier for somebody to get your password by looking over your shoulder, installing a camera in your premises or use a keyboard sniffer. In the case of password authentication, every time you log in is a weak point.
tag: youarentthatimportant - WTF? (Score:5, Insightful)
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.
More info? (Score:3, Insightful)
How could anyone really answer your question without knowing the value of the servers you are logged into? If the servers you are connecting to are in a secured bunker and you are leaving the connection open from your house while your not there and the data is something valuable enough for some to break into your house.. Well then no, you should not leave the session logged in. In general it is a bad idea to leave a connection you are not using logged in. If you are locking your workstation (you did not say), than maybe it is still ok.
Keep strict host key checking on and just log out when you are not using the box. If the key changes and your not expecting it, either someone has already broken into your server, your DNS server (on either end), or it is time to talk to the isps on the endpoints and find out which one is out to get you. The "big bad" Internet is the least likely place for you to have a security problem, it is simply too unpredictable.
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: (Score:2, Insightful)
Re: (Score:3, Insightful)
Indeed. Speaking from a military standpont (I was in communications in the Canadian Forces, Army), the longer a communications link remains open, the more chance there is that somebody will notice it. Now, the costs are a *lot* higher when you're talking about battlefield communications and the potential for enemy artillery, but the principle remains the same: if you keep an encrypted communications link open 24/7, then the chance that somebody will take notice and try to do something with it are significan
Re: (Score:2, Insightful)
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: (Score:2)
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.
Re: (Score:2)
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: (Score:2)
Windows machines behind hardware firewalls, unfortunately.
Re:Reconnect. (Score:5, Informative)
SSH doesn't use SSL, and SSHv2 has provisions for rekeying even during a single connection.
Re: (Score:2)
Re: (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 yo
Re: (Score:2, Interesting)
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:all of the above (Score:4, Funny)
Are you crazy? Obviously the two encryptions would cancel out each other!
Or... (Score:3, Funny)
When you cross the two encryption streams you may get total protonic reversal, or you may get 1 REALLY POWERFUL STREAM.
Re: (Score:2)
So what you`re saying is ... don`t cross the streams?
Ah, the feared ROT13 cypher? (Score:2, Funny)
Yes, you are correct, but you may want to upgrade from ROT-13 to ROT-26.
Re: (Score:2)
That's the same encryption I use on my luggage!
Re: (Score:2)
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.
Re:Sniffing? (Score:5, Interesting)
Re: (Score:3, Interesting)
dtach [sourceforge.net]
Re:One-time pad (Score:5, Interesting)
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 (Score:4, Interesting)
Re: (Score:2)
That just keeps it from being The Answer To Everything.
But ssh between work and home? Move the OTP over sneakernet.
A phone call to your wife? Plug the phones into each other tonight when they're charging.
Bank account access? They give you a flashcard when you're physically there to open your account.
An online order with a store staffed by people you've never met? Oops, now you have to fall back to publ
Re:One-time pad (Score:4, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
First, that would be a really difficult timing attack to pull off, as you would have to be able to reliably identify the point at which you were no longer authenticating with the remote server. Second, because ssh sends data in discrete packets that may include one or several characters, the code would have to guess how many characters were in each packet; this should make it fairly unlikely that you would be successful. Third, even if it were possible, it is trivially avoidable by including a checksum in
Re: (Score:3, Insightful)
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: (Score:2)
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 bet
Re: (Score:2)
Nope, just the ones for which it's convenient to do so. I'm not saying Diffie-Helman is obsolete; I'm saying that we sometimes use it when it would be pretty darn easy to use something even better.
You say that like it'
Re: (Score:2)
People joke about OTP and say it's infeasible, but seriously: how inconvenient is it to carry around a few gigabytes of pad? (...) And yet, if our software could use it, I bet plenty of people really would be carrying around randomized flash cards
Long story short, if it was practical to use a one time pad it'd also be practical to carry around the fingerprint and a SSH client certificate which has been added to the known hosts on the server. Verifying the fingerprint over a secure channel is a lot easier than transferring a OTP, it''s not the carrying it's that you can't send it over the Internet or the whole point would be lost. If you carry the whole OTP on a flash drive, then someone can just steal the whole OTP as easily as they steal the certif
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: (Score:2)
I'm sure ssh has some way to prevent session hijacking though.
Yes, it has. It does cryptography.
Here's the long and short of session hijacking: when you connect to (say) facebook and type in your username and password, facebook issues you a one-time "username"---something which identifies your real username---with no associated password (or, if you will, the username is the password).
Whenever you ask for a facebook page, you send that one-time username in the clear. Anyone who snoops your connection can read that username and reuse it to impersonate you.
If the sendi