Slashdot Mirror
Keep SSH Sessions Active, Or Reconnect?
borjonx writes "Is it safer to log out of an SSH session, and re-establish it later, or just keep the connection open? Like many of you, I use OpenSSH to connect to my Slackware Linux boxes remotely from Linux and WinXP (putty.exe) clients. At home and at work, I wonder if it would be safer to just leave the connection open (my clients are physically secured, the servers limit connections with hosts.allow). Is it more secure to re-establish the connection over an insecure link (big bad internet) where people can sniff that handshaking, or is it more secure to just remain connected? I connect 1 to 4 times per day, most days."
Just use the program, "screen", if you want to resume your sessions.
Seriously..
The minor advantage over one or the other is moot.. because unless you've got something of actual importance (in which case it shouldn't be on your home computer) no one is going to go through the bother of trying to break in either way.
If someone wants whats on your computer.. they'll probably just grab you and beat you to a pulp until you give them your password.
What gives you the impression that the key-exchange in SSH is vulnerable?
The short answer is: Whatever.
http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange
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.
I like screen and shwatchr then you can reconnect to your session and if it's from a unauthorized host it gets the boot!
Darwin Enforcement Agent
Is it safer to log out of an SSH session, and re-establish it later, or just keep the connection open?
Breaking the crypto is almost assuredly not the weakest point in your connection. I'd stay connected, since by far the biggest danger is user errors: you accidentally connecting to the wrong serves, ignoring a cert change alert or something else boneheaded.
Assuming you're not using SSH1, the client and server should periodically regenerate session keys, so it's not like you'll be encrypting vast sessions with just one key (not that this is likely to be the biggest point of failure in your system even without re-keying).
rage, rage against the dying of the light
....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.
Live today, because you never know what tomorrow brings
Both the persistent connection and the handshake protocol to establish a new connection are completely secure for any practical purpose. If both the server and the client are completely secure, and the connection between them is secure (via strong crypto in ssh) then pick whichever method works best for you.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
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.
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.
reconnect as needed, but tunnel your ssh over an ssh session which is always active.
Do you even lift?
These aren't the 'roids you're looking for.
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.
SSH doesn't use SSL, and SSHv2 has provisions for rekeying even during a single connection.
rage, rage against the dying of the light
I find using the screen to manage my many simultaneous SSH sessions extremely helpful. This tool is so useful it's on the same level as Adblock is to Firefox. With this tool, the reconnect/connect issue is a moot point.
It 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.
Ask Slashdot: Where bad ideas meet poor googling skills.
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 ...
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"...
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.
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.
the only thing that is important is that you verify the public key fingerprint presented by your server to prevent MITM attacks. Aside from that there is absolutely no reason to believe the ssh protocol itself has been broken.
If 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.
People using html in email should be shot.
Go outside.
I prefer a void in conversation to a vacuous one.
When you cross the two encryption streams you may get total protonic reversal, or you may get 1 REALLY POWERFUL STREAM.
How much is your data worth? Back it up now.
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.
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).
You're right, but they do both use Diffie-Hellman for key exchange, so the security implications of setting up the connection are similar.
Yes, you are correct, but you may want to upgrade from ROT-13 to ROT-26.
Make sure everyone's vote counts: Verified Voting
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.
"The large print giveth, and the small print taketh away" -- "Step Right Up", Tom Waits
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.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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.
This is exactly the sort of question that Stack Overflow was created for....
It's not the carrying around that's burdensome, it's getting the OTP data to wherever you're connecting.
True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
Not really, SSL and SSH uses the DH handshake differently. SSL performs all sort of craziness where you select different chipers, sizes and wheter to encrypt at all. SSH does not.
The ask slashdot article is about SSH NOT SSL. Session hijacking has nothing to do with SSH.
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
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.
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)
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.
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.
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 public key crypto and trusted introducers.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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 certificate or sniff the password or both. Yes, I know someone will cite the Debian OpenSSL exploit now but looking at it a different way, it was the local software that was exploitable. If you can get a security hole into the OTP software, it'll do you no good no matter how good the encryption was supposed to be. The only effective one time "pads" I've known are those where you get the code externally from a key calculator, a key card or over your cell phone which is assumed to be a secure channel. In short, OTP is fixing all the things that aren't a problem in the first place.
Live today, because you never know what tomorrow brings
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 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.
In a real emergency, we would have all fled in terror, and you would not have been notified.
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's a horrible obstacle. And yet, you've physically met your friends and family. You physically travel between work and home. You're physically at a bank branch when you open a new account. Those are pad exchange opportunities. If it's easy to do, then why not?
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Here is a better idea, do not open ssh to the world. Make them vpn in first, then ssh. Security in layers.
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 each block of text and encrypting it with the OTP just like you do with the actual stream data. If the checksum doesn't match after decoding, the packet is discarded and the sender has to resend it. Presto, no more injection attacks.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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 sending of the one-time username was encrypted, this wouldn't be possible. Like Jeff (Mr. coding horror) says, use HTTPS.
SSH encrypts everything that's sent.
(Oh, and don't listen to Jeff about computer science; a recent stackoverflow podcast made it painfully clear he doesn't know the first thing about automata and language theory. He may be a great programming craftsman and/or businessman, but I find his lack of faith^Wtheoretical knowledge disturbing.)
That's a maddeningly recursive solution...
Can you be Even More Awesome?!
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.
XML is like violence. If it doesn't solve the problem, use more.
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.
Everything I write is lies, read between the lines.
Great, now you have something that will work for 5% of the cases in which people need to remotely connect. Now how about the rest of the times when people cannot get physical access to the machine by inconvenience or by policy.
Just because its possible to do something doesn't make it practical. In fact, its usually when you impose that impracticality on people that they start doing stupid things that jeopardize their security more than it was before the "better" solution.
This initial message is what Monkeysphere is designed to fix.
Monkeysphere distributes GPG-signed SSH host keys. If you have the admin's trusted public key, and they sign their hosts' keys, you can trust the host key even if you haven't connected to it before.
http://web.monkeysphere.info/
Other than looking at the protocol itself, there is one other thing to consider that may raise the stakes more than someone's ability to crack SSH or not. By keeping yourself logged in and using a keep alive option such as TCPKeepAlive, you are further exposing your existence. If someone was listening at a router or something and wanted to find interesting hosts to break into, you're opening a larger window for discovery by leaving your session logged into 24x7. The fact that you're using SSH would tell someone that you have shell accounts in different places, which is most definitely interesting to hackers.
VPNs are somewhat easier for compromised systems to exploit, since the new endpoint shows up as a new interface... they don't have to go through the modest trouble of exploiting the SSH connection by compromising the executable, they can just run their attacks on internal systems directly through the VPN... the surface area for attack is larger.
On the other hand, if they HAVE compromised the SSH executable, having it wrapped in a VPN isn't going to add much (if any) additional safety.
So all in all, unless you're a true bastard and the VPN is terminated in a DMZ that only has the SSH servers visible (and if so, bravo to you), VPN (with or without SSH) is probably a net loss in security.
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.
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.
Or if you work for a hi-tech company with, say, technology that China (for example) wants badly enough to put their version of the NSA to work cracking you and then handing the company's designs to (for example) Huawei.
The company I work for would qualify.
The problem with the tunnel is that it can turn a successful attack on one end into a successful attack on the other. Taking it down when not using it reduces the window of exploitable time. (Which probably still doesn't make a lot of difference for attackers of major-power-intelligence-community level, so never mind. B-) )
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Another advantage of this approach is the ability to "hide" useful data inside the pad. If more people used OTPs, we wouldn't have this "hand over your keys" nonsense in courts. Take all of my data. If you cannot understand it, tough luck.
For search engine friendliness its best to call it by it's full name, GNU Screen.
i wish i could stop
Apart from all the distribution problems that everybody has been talking about, I'd like to know how you will surmount the problem of creating the pads in the first place.
To fill your 2TB disks you'd need to toss a coin 16000000000000 times (which I don't think you're willing to do) or have some beefy true RNG (hotbits generates 100 bytes/second, you'd have to have it going for 2500 years).
Pseudo random is not good enough, and RC4 would give you a similar result if you used a cryptographically secure PRNG (and much better if your PRNG is not good).
GPG 0x1B479C78
If somebody manages to crack DHE this guy's home server security will be the least of our problems. The algorithm is pretty straightforward.
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.
They don't have to crack DHE in general, all they need to crack is diffie-hellman-group1-sha1.
Since a fixed DH group is used, this could be attacked through precomputing many values for the discrete logarithm.
If the key negotiation happens to fall into one of the precomputed values, then that session is in trouble.
If you are really worried about having an insecure link you could try creating a tunnel or VPN between the two machines. These can be long term connections setup indefinitely and have provide their own layer of security. Then just make sure you SSH through the VPN/Tunnel to get back to the server. This will protect your hand shaking between the two systems.
Also be sure to have you private/public keys setup. For ease of use they do not need to have a password (although they can), which is handy for using scp.
However this seems like overkill to me. I am in a similar situation where I SSH home, but because I am a small time home user I find the security provided by SSH and private/public key encryption good enough for me.
In my opinion there is no answer to this question. Both scenarios are subject to an equal amount of risk. The most important thing is securing the workstation itself. If done properly, the risks of staying connected or re-connecting are self-canceling. Do what is most convenient for you, just make sure your workstation is as secure as it can be.
...google.nl/...
But that's in Dutch. He meant a new word in English.
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.
Nah, the original question says the guy is using puTTY and OpenSSH. They both implement RFC4419.
we already have a great structure for the distribution of OTPs .... trillions and trillions of bits distributed around the world. We call them record stores - by the same CDs, rip them and use the LSBs
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.
Here is a better idea, do not open ssh to the world. Make them vpn in first, then ssh. Security in layers.
There is little to no additional security in that. The problem isn't getting cracked from the network it's getting cracked on your client machine.
Not that there's anything wrong with putty per se (AFAIK), but the underlying platform is a concern. Sure, putty will send everything over SSH back to your Linux boxes at home, but there is more than a little malware these days that logs your keystrokes, something against which SSH cannot protect you. I would only log into the home machines from your Linux machine at work, and even then only if root belongs to you. It's unlikely your employer would be using keystroke loggers, but they could; it's not illegal if they tell you, and maybe not even if they don't. The usual boilerplate in network access policies could be interpreted to mean everything from log scanning for anomalous activity to recording everything you do.
Next, set up public/private key login and don't allow password login. I do this even within my internal network, and there are no Windows machines on it. At work, where Mac, BSD, and Linux are the majority of the boxes, of course I do it too. Those boxes may be fairly secure and there aren't a lot of Windows boxes on my part of the network, but not trusting any box you don't control is a good idea.
As far as the connection duration, I'd leave them up all the time unless there is some other operational need not to.
"Is it safer to stay in the car, or is it safe to go outside? Like many of you, I use a car to go to work and whatnot. At home and at work, I wonder if it would be safer to just stay in the car then going outside. Is it more secure to lock my car with a key (big bad parking lot) where people can come up and steal my keys, or is it more secure to just remain in the car? I use my car 1 to 4 times per day, most days." On a serious note; when you have used so much time to secure your connection why not used now and then.
"Is it more secure to re-establish the connection or to just remain connected? I connect 1 to 4 times per day, most days."
Since you make new connections on a regulary basis the question does not makes sense: either way, your encryption keys are likely to be known in advance by your opponents (even before you start a new connection). If you have anything worth being protected, start questionning yourself about the very simple steps you are following to transmit your data (and where it made sense for opponents to dig into).
Why use hosts.allow? isn't that a rather old and crufty way of doing it...
How about using iptables rules to allow certain hosts instead, that way someone who isn't authorised to connect won't even see the ssh service port open and won't be able to cause load on your machine by repeatedly trying to connect.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Read the big red book "Applied Cryptography: Protocols, Algorithms, and Source Code in C". http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-Source/dp/0471117099/ref=sr_1_1?ie=UTF8&s=books&qid=1265363727&sr=8-1 Highly recommended to anyone who uses public key encryption or needs to implement VPN's, mail encryption or tunnels.
In essence, no it doesn't make any difference. However, if for example you application would communicate short commands often through public key encryption it would be more economical to use persistent connections instead of making new connections all the time. Key generation is Expensive.
Also, in you situation, just use screen.
How in the hell does retarded 'ask slashdots' make the front page, but not my submission of http://itpomminpurkaja.blogspot.com/2010/02/css-anchor-pseudo-class-concerns.html and http://www.fizzl.net/ for which I actually expended some effort to create.
Bot Assisted Blogging
You seem to have concentrated entirely on breaking the encryption. However, if we assume that this is hard to do (which your post seems to indicate) doesn't continuously making new connections put you more at risk of a man-in-the-middle attack whereas an already established connection cannot be interfered with in this way without first breaking the encryption?
I've been thinking this same thing (using USB keys for a OTP, and "why don't we do that?") for a couple years now, but 10 minutes after reading your post, the following problems/"considerations" with the USB OTP approach did start to enter my mind:
1) I can see that with a big 2TB pad, you'd also want/need to cycle through pads... the longer you keep the same pad without destroying it, the more data an attacker can get with rubber-hose cryptography if they recover your pad... by coming to your(or his/her) house with a gun and ripping the USB key off your neck. Or seizing it when you/they travel.
2) Also, the other trouble I can forsee with OTPs is that you need one of them for each person you need to communicate with securely. Typically if you are doing something needing this security, you are not doing it with just one other person... you also need to communicate with multiple parties. Once you have 5-10 parties to communicate securely with, the OTP can get a little cumbersome. Carrying around 5-10 USB keys and keeping them straight? And I can't envision it working with 200+ counterparties (a USB-OTP-for-the-web scenario). If you partition your 1TB USB into, say, 10 parts, one for each counterparty, you still have problems. You still need to get 1/10th of that USB key to each of the other parties without giving them the other 9/10ths of the key. (Or your whole gang could use a set of the same 1TB keys and you are trading off convenience versus chances of an informant/leaker, and if you're paranoid enough to be using 1TB OTP, why make that tradeoff?) And don't the counterparties need to communicate so they need their own web of keys?
3) There is the little problem of USB-PC security: wouldn't putting the USB key in a PC expose your whole OTP to the perhaps-infected PC? How does this actually work?
One can see that subversion-resistant secure random number generation, secure transport, and secure key usage, and secure key destruction are all required to make OTPs actually secure.
I predict someone will attempt to market USB one-time pads within 5 years as a sort of snake-oil bandaid, and I can see a distant future where they get used, but I don't see them becoming used widely/securely particularly soon. (Disclaimer: bank tokens that give you 5-digit codes for authenticating transactions do make a lot more sense to me however and might be one targetted use of this technology.)
--LP
P.S. I have not read the security literature on one-time pads. Forgive me if I'm stating the obvious.
P.P.S. I was kind of stunned last week though when getting a mini-SD card for my phone that I can, for $50, get something that is literally the width/length/thickness of my pinkie fingernail that contains 8GB.
LOL .nl is just me.
All the results are in English as you might have noticed, the
I'm actually interested in languages and new words...
"Kill 'em all and let Root sort 'em out"
Is a really long RS232 cable. Stretch it between your home and work.
You're comparing oranges and orangutans.
Damping absorbs vibrations. Dampening is caused by moisture.
It's not like you re-use "one-time" pads, so what does your correct guess + xor gain you?
When you talk about generating 2TB of pad, I gotta admit, that sounds formidable. But it's a question of quantity/time. Generating numbers is easy; I just don't know how long it would take to come up with 2TB.
Many of us walk around every day, carrying a device that contains a radio antenna and microphone. It probably has a SSD, and maybe has an accelerometer. It passes through yogsothoth-only-knows-what environment, constantly filled with each person's totally unique mundane minutia and perspective. Your best-funded worst enemy has no chance of recreating that. Gathering entropy is easy, it's just a questions of bits per day.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Want a still better idea? Keep ssh open, but forbid passwords.
Voila! No Chinese computers accessing your network, and you still have a secure channel from the outside.
I don't understand why the BSD folks still think the default configuration of ssh is secure enough. Inertia, maybe, or backward compatibility?
Rethinking email
That is probably the best criticism anyone has brought up.
OTP still belongs in our toolboxes, though. 3DES doesn't solve any problem AES has and RSA doesn't solve any problem D-H has, but you still have 3DES and RSA. What I'm saying is that if you can generate and share the keys easily and securely (and I'm totally convinced that people misunderestimate just how often that isn't a problem) then it has no other downside. I can flip this around
and say that when I'm copying those keys, I often (not always , I'll admit) could just as easily copy a few gigabytes of OTP. Think about your ssh connection between home/work (assuming you work in an office that you visit every day) or a phone call to your spouse. In such situations, all of OTPs disadvantages would be overcome so trivially, that people would use it if their tools supported it.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
these aren't home servers - these are production servers at work. they're in the data center, so i ssh to them, weather i'm at work or home.
Modification of plaintext is easy when the attacker knows what the plaintext will be. Since OTPs generally use XOR to combine the plaintext with the key, the attacker only has to XOR the known plaintext with the modification and then XOR that with the Ciphertext:
P = plaintext
K = key
C = P ^ K = ciphertext
N = attacker's desired new text
A = P ^ N = attack string
M = C ^ A = MITM modification by attacker
The recipient decrypts M with K to get: plaintext = M ^ K = (C ^ A) ^ K = ((P ^ K) ^ (P ^ N)) ^ K = (K ^ N) ^ K = N
The attacker has modified the ciphertext stream to inject N into the new decrypted plaintext, knowing only P.
This works on a per character basis, so the attacker just has to know where in the ciphertext stream the known plaintext is.
Difficult timing? Just wait for a delay after the initial burst of login traffic, and watch for the 5 characters to come after that as the user types "mail\r". ssh generally sends individual keystrokes as separate packets to the remote host unless they're grouped into one large write on the client side, so it would not be hard to identify sections the user is typing. Even in a completely batched protocol, just observing the packet sizes long enough would allow an attacker to make a good guess about how long the initial exchange is, what the byte offset is, and how long the first command is and whether it's always the same length.
Including checksums in the block does not help the case for OTPs. CRCs will be unchanged if the plaintext modification is divisible by the CRC polynomial. If the entire plaintext is known, the CRC (or any checksum or unkeyed hash function) can just be modified as well. What you would actually need to do is replace the OTP with a one time codebook encoding each possible n-bit message as an (n*2)-bit random code (and using a brand new codebook for every message) so that an attacker would have a 1/(2^n) probability of choosing a different valid ciphertext for any given message, which is the same probability as an attacker guessing the original plaintext and therefore as statistically secure as the OTP (but not provably secure; there is no way to prove that you can prevent all MITM attacks or even prevent data loss).
Or you could just make the checksum be a hash of the last dozen or so packets of communication history so that the attacker can no longer practically know the complete plaintext. Alternatively, you could add a randomly-generated piece of data into each packet that provides an additional value to add in during the hashing of the following packet.
Check out my sci-fi/humor trilogy at PatriotsBooks.
http://xkcd.com/538/
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
Most appreciated. Thank you. :)
Serious? Seriousness is well above my pay grade.
One needs to stage man-in-the-middle attack to hijack existing session, whereas broken handshake can be used to establish new connections. Not looking at crypto-analysis, keeping connections open is much more secure ;-)
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!"
Even if you received an email beforehand coming from your sysadmins indicating that they had installed a new version of SSH and because the key had changed so don't worry about any warnings. If they can manage a man-in-the-middle attack then faking an email will be trivial.
In which case my original statements still hold.
If you maintain a connection when you are not physically present you have downgraded your security to nearly non-existent. Your unattended computer is not secure if it is powered on. It is vulnerable to physical attacks and to zero-day exploits that it would not encounter if it were turned off when not being used.
If you make a fresh connection to a host that you have already got the host keys for - that italicized clause there is what protects you from man-in-the-middle attacks - you are making a Diffie-Hellman key exchange which is not crackable by sniffing and cannot be brute-forced in real-time. A fresh connection is vastly, fundamentally safer than an unattended computer, even if your computer is locked in Superman's Fortress of Solitude.
If you aren't familiar with how DHE works, you should check it out. Very elegant and simple.