HostKey Management

Mike Kelly mike at
Thu Jan 17 02:40:59 EST 2013


As far as I can tell, when working in an environment with many servers,
there seem to be several ways for your client to authenticate the
HostKeys of each:

1) Set StrictHostKeyChecking=no, and hope you don't get MITM'd the first
time you connect to a server.

2) Use SSHFP records (which generally requires you to have DNSSEC fully
deployed to be meaningful compared to #1, I think?)

3) Build a massive /etc/ssh/ssh_known_hosts file with $N * $M entries,
for $N servers using $M hostkey algorithms.

4) Use ssh-keygen to create a single "host certificate" key, and have a
secure process to use to sign the host keys on all of your servers.
Then, put that certificate in /etc/ssh/ssh_known_hosts on all your servers.

5) Use the same HostKeys everywhere, and just put those keys in
/etc/ssh/ssh_known_hosts using a wildcard for your whole domain (e.g.
"* ssh-rsa AAAAA....."). This makes revocation very
difficult (since you need to securely re-key all of your servers).

I also saw some discussion recently on this list about storing hostkeys
in specialized security hardware. I'm not familiar with how "that stuff"
works, but I assume it doesn't scale very well when you get up to
thousands of servers, without a significant increase in your cost?


So, my questions are:

1) Is there some other option that I'm missing above?

2) Are there any good resources on "best practices" for any of the

3) Are there any tools that help make maintaining one of the above

4) Many of the above options seem to make revocation somewhat difficult
(especially #5), but I think that in most other cases, "@revoked *
ssh-rsa AAAAA...." should work to revoke a stolen key for a specific host?

5) How do "cloud" people handle host keys? As far as I understand, they
often spawn and destroy many instances of servers over time, but I
assume they still want to be sure they're reaching the right host somehow?

For any answers to the above, a solution which requires minimal/no human
interaction would be basically required. It's assumed that, say, public
keys would be set up via some "other channel" to allow whatever access
is required.

Any advice would be appreciated.

Mike Kelly

More information about the openssh-unix-dev mailing list