Security (both physical and infosec) is one of my biggest passions, and I've been writing about it for plenty longer than a decade. Granted, for the first several years, it was a pile of .txt files in an "e-Zine" but still...
I don't think that he thought there was anything wrong with it. He was expecting a write-up of 'what not to do,' but instead got Google search results for the Darwin awards, so he laughed.
I caught this via a friend of mine, and I tried it without a site: search and mostly came up with too much noise to signal in the results. I'd imagine that a lot of "paste over the Internet" sites have this problem, and I'd bet SSH keys aren't the only juicy bits you can find.
The reason that the first hit has "penis" embedded in the base64 is that I posted this to Reddit last night :-). I figured this sort of thing would be old news for HN, but judging by this having gotten 8 points in 12 minutes I guess I was wrong.
Because you're still in the process of setting up an actually secure SSH in the first place?
If you're serious about security, scp is not secure (open to man-in-the-middle attacks) until you've transferred keys via some other channel or use a PKI that you actually pay attention to.
Say what? scp is perfectly secure (not open to man-in-the-middle attack) without transferring any keys or using any PKI. scp (just like ssh) asks you to verify remote key fingerprint on first connect.
If you're setting up a new server, you either have physical access and can use a keyboard and monitor to look it up, or it's hosted by people you are paying to do such things as tell you the key fingerprint.
Just to be clear mbreese is talking about if you have just set up a new server like a vps and when you first ssh/scp to the server you accept a compromised key such as through a MITM attack but as he said this is highly unlikely to occur.
I setup a VPS on Linode, and they actually added the SSH RSA/DSA key for the 'admin console' login (Lish) when I asked about it on IRC. So, for first-time setup, you can lookup _that_ key, then from there, lookup the system key itself. This avoids a compromised key, at least from you to Linode.
Hopefully Linode doesn't have any internal gremlins.
Of course, the weak point there is SSL where the keys themselves are transmitted, but it did well to quell my paranoia.
1. If you are setting up servers, you don't need to transfer private keys anyway. You may want to transfer client public key to server, but that is absolutely unrelated to man-in-the-middle, paranoia or anything.
2. If you are setting up servers, you may want to transfer the server public (not private) key to client, but what's the point? Ssh/scp will do it for you anyway, and you already know the remote end public key fingerprint anyway -- since you are setting it up.
So, no, "ultra-paranoid" doesn't explain the pastes in question. "Ultra-ignorant" does :)
Techies almost always consider themselves quite smart. However, a big fraction of them are egregiously ignorant of important technical matters. Security has always been a problem area as far as this goes.
(OO and compiler/language implementation are two more!)
if you want to set up seamless logins of an account to anywhere from anywhere, you need to copy around both because any node could either be on the client or server side of the challenge and response.
He didn't say it was the right way to do it. He didn't even say what he was describing was a good idea. He just offered an answer to the question, "Why would people copy a private key around?". Obviously, people are doing it for some reason, misguided as the reason may be.
You're absolutely correct, but it's actually pretty common to distribute that public key all over hell and then start shuffling the private one around between the ones you find yourself ssh-ing off of. At my last job, this practice among wayward sysadmins caused me a lot of gnashing of teeth.
Wrong move though - really there should be one key per machine - and then ssh-agent set up properly to take care of the intermediate machines so you can bounce around. Using the same private key on multiple machines is just asking for trouble when you need to revoke something...
Oh, believe me, I know. That's why I said it caused me much gnashing of teeth. SSH, particularly OpenSSH, is such a thing of beauty. It's a shame most sysads that I've dealt with abuse it like it's rsh and telnet.
I'd agree that uni-directional transfer is an edge case when you have only one server.
Unfortunately for network security, that seems less and less the case these days. I definitely find myself ssh'd into two remote systems relatively often and have a need to copy files between the two. (Swapping arguments to scp is not good enough.)
An example would be a cron job that copies files to a backup server via scp or rsync over ssh. However, this should also be accompanied by host filters in the authorized_keys file to restrict access to specific hosts.
Using pastebin for this is wrong on so many levels.
This is why Net::SSH and Paramiko are so wonderful. Using the OpenSSH binaries through a pair of pipes is certainly a pain, but if you grok the protocol, either of those libraries can make it really easy to wire up secure pipes between machines.
Sysadmin has two worksations - say a laptop and a desktop. He wants to SSH into all his remote boxen from either. The default reaction might be to just copy his already-authorized private key to his other machine just for ease of use - the proper solution would be to generate a new keypair on the new machine and then copy it to the required remote machines as well, so either can be revoked and tracked separately.
Wow, wait, I don't get it. You can copy from anywhere to anywhere with just one set of public private key.
for example, copy file from local machine:
scp some_file.tar.gz alex@remote_ip:~/
now copy the same file from a remote to the local machine:
scp alex@remote_ip:~/some_file.tar.gz ~/
But seamless logins form anywhere to anywhere in the way you described seems like a bad idea, unless you are willing to implement kerberos, ldap and nfs4, in this way you can just log in into a client machine using your existing credentials (see PAM) and if you have your home directory property mounted you can have public/private keypair on that machine. But this is a lot of work.
Ugh. don't do that. if you /must/ have a system like that (and it's never a great idea) keep your private keys on one box, and enable agent forwarding. It's not as good as just enabling the one-way ssh, but it's not nearly as bad as scattering your keys.
Why does everyone seem to think it's okay to build a system where any one compromised box can compromise the rest of the system? this 'jelly doughnut security' is really popular among the PHB types, because it's easy, but it just seems really, really dangerous.
Like with the whole "sniffing tor exit nodes" thing [1], you do wonder if it's actually the original owners who fails to protect their data, or if it's someone else [2].
Not that you'd want to do so, but if you're inclined to use a pastebin for such things, I have https://privatepaste.com which does not expose pastes to indexing unless specifically requested in the vhost configuration.
So whats the attack vector here? You have unknown users private key to a unknown service. Of course you should keep your private keys private, but exploiting this takes quite a stretch.
I'd missed that story, it has a point, in that passwords are a very poor solution to that problem. But, if you're going to use them, you should change them regularly.
But you should write them down and keep them in a secure location. Just like you keep a backup of your private keys...
This is not about a conctete attack. It is about a fundamental lack of care and understanding in crypto security. These Google results demonstrate the utter sluttery of various system administrators.
In the same vein: Buffer overflows should never be tolerated, even if they were un-exploitable in some cases because of lucky circumstances.
It's particularly funny because on the one hand, these people are doing something of non-trivial technical sophistication, and on the other, they have zero understanding of what they're trying to accomplish.
This would be people posting their private key by mistake when someone asked for their public key to put in an authorized_keys file. Hopefully the geek on the other end told them "WTF go burn your key and start again".
76 comments
[ 6.0 ms ] story [ 153 ms ] threadNice find and nice tip, I must say. :)
Security (both physical and infosec) is one of my biggest passions, and I've been writing about it for plenty longer than a decade. Granted, for the first several years, it was a pile of .txt files in an "e-Zine" but still...
http://www.google.com/search?hl=en&safe=off&q=site%3...
Another fun one to find Cisco VPN configuration files, many of which have an encoded (reversible) password within: http://www.google.com/search?q=filetype%3Apcf+Main+Descripti...
headdesk
http://news.ycombinator.com/item?id=639976
http://www.google.com/search?hl=en&safe=off&q=site:g...
only a few actual hits in there.
If you're serious about security, scp is not secure (open to man-in-the-middle attacks) until you've transferred keys via some other channel or use a PKI that you actually pay attention to.
But that is being ultra-paranoid in my book.
Hopefully Linode doesn't have any internal gremlins.
Of course, the weak point there is SSL where the keys themselves are transmitted, but it did well to quell my paranoia.
2. If you are setting up servers, you may want to transfer the server public (not private) key to client, but what's the point? Ssh/scp will do it for you anyway, and you already know the remote end public key fingerprint anyway -- since you are setting it up.
So, no, "ultra-paranoid" doesn't explain the pastes in question. "Ultra-ignorant" does :)
(OO and compiler/language implementation are two more!)
This would be a good topic for interviews!
Generate the public/private pair on the client machine and the public key is the one you put on other machines to SSH into them.
And if you do require both directions, you should generate separate keys on each host and just exchange the public ones.
Unfortunately for network security, that seems less and less the case these days. I definitely find myself ssh'd into two remote systems relatively often and have a need to copy files between the two. (Swapping arguments to scp is not good enough.)
An example would be a cron job that copies files to a backup server via scp or rsync over ssh. However, this should also be accompanied by host filters in the authorized_keys file to restrict access to specific hosts.
Using pastebin for this is wrong on so many levels.
I can't think of any reason at all to copy the private key though.
Sysadmin has two worksations - say a laptop and a desktop. He wants to SSH into all his remote boxen from either. The default reaction might be to just copy his already-authorized private key to his other machine just for ease of use - the proper solution would be to generate a new keypair on the new machine and then copy it to the required remote machines as well, so either can be revoked and tracked separately.
for example, copy file from local machine:
scp some_file.tar.gz alex@remote_ip:~/
now copy the same file from a remote to the local machine:
scp alex@remote_ip:~/some_file.tar.gz ~/
But seamless logins form anywhere to anywhere in the way you described seems like a bad idea, unless you are willing to implement kerberos, ldap and nfs4, in this way you can just log in into a client machine using your existing credentials (see PAM) and if you have your home directory property mounted you can have public/private keypair on that machine. But this is a lot of work.
Why does everyone seem to think it's okay to build a system where any one compromised box can compromise the rest of the system? this 'jelly doughnut security' is really popular among the PHB types, because it's easy, but it just seems really, really dangerous.
[1] http://arstechnica.com/security/news/2007/09/security-expert... [2] http://pastebin.com/f4b10cc33
You should rekey your network on a regular schedule at least as often as you change your passwords.
So, never? http://www.boston.com/bostonglobe/ideas/articles/2010/04/11/...
But you should write them down and keep them in a secure location. Just like you keep a backup of your private keys...
In the same vein: Buffer overflows should never be tolerated, even if they were un-exploitable in some cases because of lucky circumstances.