Comment by js2 | Hacker News Reader

Comment by js2 | Hacker News Reader

Of course, this doesn't address what I consider the greatest weakness in using ssh - distribution of host keys.

By design, ssh does not make use of certificates. So there is no way for ssh to know upon connecting to a host for the first time whether the public key presented by that host is authentic. After the first connection, ssh caches the keys in ~/.ssh/known_hosts, and will then give you a big warning if the key changes. I imagine when this happens many folks blindly delete the the cached key and re-connect.

So you should be aware of the potential for MITM attacks to occur unless you have some out-of-band mechanism for distributing or authenticating host keys.

Edit: huh, apparently ssh added support for certificates. "ssh-keygen supports signing of keys to produce certificates that may be used for user or host authentication." So now you just need to distribute your CA certificate everywhere and you're golden. http://justanothergeek.chdir.org//2011/07/howto-authenticate...

So now you just need to distribute your CA certificate everywhere

As opposed to writing down the key signature of your server's host keys on a card in your wallet? You only need to look at it the first time you connect to the server, and it's a lot less of a pain in the ass than trying to install custom CA certs on every machine you SSH from.

If you have one server, that sounds great. If you have 60, it does not.

If you have 60 servers you are hopefully using some kind of configuration automation, like puppet or chef...?

Yes, but in my experience, doing that for client machines (where you need to check the fingerprints) is pretty atypical.

For the love of god why have 60 servers with ssh available open to the world? Ssh through trusted gateway machine! Then you need a single signature you trust and you can firewall off the rest of your hardware.

For the love of god why would you assume this has anything to do with "open to the world"? When I proxy through the trusted ssh gateway to the firewalled servers (using ssh ProxyCommand), I still like my client to verify the signature.

I would assume that if your internal network is "trusted", then the risk of a MitM is low enough that you wouldn't have to check the signature. I agree that an extra layer of validation is always a nice thing to have, but everyone has different levels of acceptable inconvenience with regards to security.

You could store the signatures on one server, and import them in bulk. Then you still just need to write down the one signature.

Yes, there are many ways you can work around the problem of ssh needing manual inspection of individual host keys, and the method you propose is pretty reasonable. But building the verification into the infrastructure is a very sensible and nice way of handling it, and lets everyone throw out their individual ad-hoc solutions to this problem.

Or if you're running windows you can use group policy and windows PKI to get it done automatically. But I haven't found out how to do the same thing under a nix environment.

You can put SSHFP records in the DNS. See "VerifyHostKeyDNS" in the SSH man page. You'll also want DNSSEC set up of course.

After you get a validating stub resolver, since your OS probably doesn't ship with one by default.

Doesn't take long to do an "apt-get install unbound" and then modify your network settings to use 127.0.0.1 as your resolver.

And if you're using a DNS service that doesn't support SSHFP records, you can generate and distribute a base known_hosts file with your favorite configuration management solution.

While many suggestions are correct, i also like the monkey-sphere one because its based on GPG trust model.

With the CA you have to have a base trust in a CA cert, with GPG you trust whatever you want.

Even though MITM is a very important attack vector, we've seen recently how the strength of the private key file encryption can overnight come under scrutiny of world-wide IT media (spoiler: Linode private key has a 'secure' password):

https://blog.linode.com/2013/04/16/security-incident-update/

Reply on news.ycombinator.com