Is it safe to publish ssh public keys?

RichardBronosky · 05-24-2007, 12:15 PM

For my company, I would like to add a page to our internal wiki that everyone could append their ssh pub keys to. The idea is when developer D needs access to one of admin A's machines he asks to have a user created. When A does this, he usually responds with, "Done. Your password is 'password' please change it." I would like to have A create the user and paste the ssh pubkey from the wiki into ~D/.ssh/authorized_keys2 so that password doesn't even come into play.

So, with that said:

Is it safe to share your public ssh keys?
Sure, putting this on an internal wiki provides a certain level of security. But how safe is it?
If I were to paste my pub key right here on LQ dot org, how could that be used against me?

This question is probably for the l33t-est of crypto buffs, but I'd also like to hear of any cases that anybody has about doing this. I want to know just how public, public keys have been (or can be) made.

Please discuss.

anomie · 05-24-2007, 12:32 PM

As per the manpages for sshd(8) the pubkey contents are not highly sensitive. So the short answer is that the setup you're describing is probably ok. The biggest danger I see with it (and this could be a serious problem depending on your situation) is a user mistakenly posting their private key.

P.S. No, I would not share my ssh rsa/dsa pubkey with the world. Unlike gpg public keys, there is no good reason to do so. (And I'm that paranoid.)

RichardBronosky · 05-24-2007, 12:48 PM

Quote:

Originally Posted by anomie

As per the manpages for sshd(8) the pubkey contents are not highly sensitive. So the short answer is that the setup you're describing is probably ok. The biggest danger I see with it (and this could be a serious problem depending on your situation) is a user mistakenly posting their private key.

P.S. No, I would not share my ssh rsa/dsa pubkey with the world. Unlike gpg public keys, there is no good reason to do so. (And I'm that paranoid.)

Well, one other possibility is that someone finds your pub key and decides to social engineer you. They find out that you regularly ssh into example.com. They decide to register a few fat finger versions of that domain and point it to a honey pot, which you eventually hit. You don't notice the warning that forces you to type 'yes' to except the finger print of the new machine (Hello!?!?). And once you get logged in, the first thing you do use sudo, which prompts you for your password... This is so highly unlikely, that quite frankly, I don't think it's worth considering.

anomie · 05-24-2007, 12:53 PM

Definitely that's worth considering. I think this will come down to how secure your data / services need to be. If there is zero tolerance for this being a potential security hole, it may not be worth it.

As a side comment: the openssh client (by default, via StrictHostKeyChecking) won't even let you authenticate if the fingerprint does not match. I believe I've seen Windows clients that do what you're describing -- i.e. allow you to click 'yes' to continue anyway.

RichardBronosky · 05-24-2007, 12:54 PM

I have actually seen people ask, "will you just shell into my machine and..." in a public discussion. This is where a shared pub key could occur.

Heck, with the power of chroot and GNU Screen, I've been tempted to ask that myself a few times.

Also, if you ever email a pub key (without GPGing the entire message), you might as well be posting it on the web.

RichardBronosky · 05-24-2007, 01:04 PM

Quote:

Originally Posted by anomie

Definitely that's worth considering. I think this will come down to how secure your data / services need to be. If there is zero tolerance for this being a potential security hole, it may not be worth it.

As a side comment: the openssh client (by default, via StrictHostKeyChecking) won't even let you authenticate if the fingerprint does not match. I believe I've seen Windows clients that do what you're describing -- i.e. allow you to click 'yes' to continue anyway.

No, I'm not talking about the fingerprint mismatch/man in the middle alert. I mean the thing that happens when you try to shell into a host that is not in your ~/.ssh/known_hosts file. Like what happens the very first time you try to connect to a new machine.

As demonstrated by:

Code:

rbronosky@ubuntu:~$ sed -i '/dev1/d' .ssh/known_hosts
rbronosky@ubuntu:~$ # That removed the 'dev1' entry, making it look like I have never been there.
rbronosky@ubuntu:~$ ssh dev1
The authenticity of host 'dev1 (10.10.10.52)' can't be established.
RSA key fingerprint is b4:14:04:b5:48:7f:5d:1a:a8:e5:eb:0b:0e:f3:c6:41.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'dev1,10.10.10.52' (RSA) to the list of known hosts.
Last login: Thu May 24 13:55:41 2007 from ubuntu
rbronosky@dev1:~$

Brianetta · 06-01-2007, 07:55 AM

Here's my public key:

Code:

ssh-dss AAAAB3NzaC1kc3MAAACBAPhWqqLb+HDmtKHJBipcZ4BvqnYNVbKF7drJm0HP2RVj7uVJtnyUaOqZZYOjyXoRW5xsuj6DRPenoCaPZZv7cGn7fjDz60Iqm3P4zgrHqEl6h4qkzH/k6D7b1s8QRCngmvowo8YMA7NX4mPhiyWmBJWETUizKyz5kBLNfrJzqq/FAAAAFQDfqh6lzJLoRaYdt77a8sQ/wwMfyQAAAIEA9ri1OXfbv+vBEvgEkDO5ouqcsekSwYMb/AQ6EnwYv0El5z+HULlnsvq1PAeGR/fxlnT2mLBHXaQqG1kPQIcPtVON8JOjBWJhAMKzWtGlyWoZ/iX8lGV6GFzNsp1wKnoUBvKoNOv8v4EJN2IOb1NyDHxpuVN8UDH7J+BV5soqdqAAAACARTJzGl0eobdJM/4VivzqeRHIhsa7mtxcNPYImS0QBi4PPEGxCd4GrM2LbIO8tm3dMCmTIlQDJcjbfxP+IOgRAJPJcwZDknQLncDvatnNaJJ41VddMDBCoTvFSB9IOp0hrN0lhtE7LGs30OvShMFpzmT4cLfaPKx5ceW9yabQdYQ= Brian Ronald

As you can see, I'm quite happy to share it globally. I'm comfortable with my understanding of public key cryptography, and I understand that it's highly unlikely that my secret key can ever be derived from this public key.

I always check the host fingerprint of a machine to which I'm connecting. If I'm prompted to check a print on a machine I use regularly, I check it out - usually by some non-ssh means of contact.

As long as you understand what you're doing, it's very safe. Just like a lot of things in life. (-:

sundialsvcs · 06-09-2007, 09:11 AM

It is quite reasonable to allow users to provide their public keys to you, and you to them, as a means of identifying each of you.

But I would not arrange a system so that your user's public keys are unnecessarily exposed to each other, that is to say without their knowledge or consent.