How Not to copy your SSH private key to your servers | Hacker News Reader

How Not to copy your SSH private key to your servers

google.com

309 pointsax0n72 comments

Why would people copy a private key around?

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.

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.

Seems like that's a serious edge case. Most times (IMHO) you'd be going one direction.

And if you do require both directions, you should generate separate keys on each host and just exchange the public ones.

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

Doing so, you expose yourself in propagating penetration from a compromised server to a previously secure one.

In that case, use an ssh-agent and agent forwarding. Then you only need your private key on the box you're actually sitting at.

Unless you want to use headless logins...

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.

For obvious reasons, you're much better off generating a new keypair for that (not reusing any existing private keys).

Automating ssh, however, is surprisingly painful.

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.

Why wouldn't you just generate a new key pair?

With python you have Fabric and paramiko which makes automating ssh very strait forward.

Isn't that a pretty broken design? Copying private keys around sounds like a really bad idea.

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.

I feel like I'm missing something here. Why would someone copy around a single private key instead of generating a new key pair for each user@host?

You don't need to generate a new keypair - just copy your (single) public key to the authorized_keys file on each machine.

I can't think of any reason at all to copy the private key though.

No that's backwards - the reason is laziness.

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.

So, you're saying that people paste their key online so they don't have to carry it around on a USB stick? Wow.

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.

That's what I meant. I simply could't believe that someone would do this.

ssh-agent?

Or create a pair for each...

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.

Old news for the man that hacked Hacker news, but certainly not for mere mortals like me :-)

http://news.ycombinator.com/item?id=639976

You are over-estimating HN :-)

Well, Twitter only allows 140 characters, so...

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.

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.

Key oriented scanners exist, in fact they became wildly popular after the 2008 Debian openssh randomness debacle.

You should rekey your network on a regular schedule at least as often as you change your passwords.

at least as often as you change your passwords

So, never? http://www.boston.com/bostonglobe/ideas/articles/2010/04/11/...

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

For starters anyone with access to the pastie server logs has your IP which would be a great starting point.

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

[1] http://arstechnica.com/security/news/2007/09/security-expert... [2] http://pastebin.com/f4b10cc33

Or pastie.org if you prefer:

http://www.google.com/search?hl=en&safe=off&q=site%3...

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.

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

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

This would be a good topic for interviews!

What? Pastebin and the Google cache is a perfectly legitimate backup strategy!

Oh wow. That made me laugh as it caught me a bit by surprise since I expected yet another security blog.

Nice find and nice tip, I must say. :)

Hey now! What's wrong with security blogs? :P

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.

Why would you use anything other than scp?

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.

This only works if you know the remote key fingerprint in the first place. If you're setting up new servers, it could potentially be compromised.

But that is being ultra-paranoid in my book.

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

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.

Even in that case, scp would still be a better option than pastebin.

even gist.github.com

http://www.google.com/search?hl=en&safe=off&q=site:g...

only a few actual hits in there.

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.

That's a nice service, but it is still no option for transferring private keys.

Indeed. Why would anyone trust a 3rd party website with the private key?

I burst out laughing after clicking that. I feel bad for those people.

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.

I am confused, how did these keys get put on paste bin? Did people place it on paste bin thinking each paste is private?

check out Johnny Long's Google Hacking Database, full of examples like this http://johnny.ihackstuff.com/ghdb/

I think I just heard tptacek's head explode.

Really? I think I just heard his bank account increment.

I think it'd take much more than ridiculous key handling to make Tom's head explode..

lol, funny to see people who are presumably knowledgeable about internet completely forgetting about security

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

I know, because I run a free shell server and I used to ask people to provide public keys, maybe 1/20 would send me the private key instead.

Dumbos, all those keys aren't even encrypted. Some people should not be allowed to use a computer.

google is often used by script kiddies to find common vulnerabilities in websites.

really ? gosh, that is news

So what is the news in the case of the link posted by the op?

that are all on pastebin, not on "your server". so these are all worthless keys anybody can generate in a second on a linux box. thats not news.

Reply on news.ycombinator.com