Managing sshd Keys

One of my pet peeves is blindly accepting ssh server keys. This is usually cause by a lazy or uninformed Sysadmin who has failed to properly manage his server keys, but secondly by users discounting the importance of verifying server keys and not demanding their credential validation process be better protected.

As a server admin you have these responsibilities to your users:

• Proper record keeping of your server keys
• Backup/Restore procedures for server keys
• A well defined process for publishing the server keys to allow easy validation by users.

As an ssh user, you have these responsibilities to your organization to maintain confidentiality and protect your own non-repudiation:

• Do not blindly accept unknown ssh server fingerprints when you first connect to a server.
• Initiate an incident when you your ssh client claims a problem with previously validated server keys.

When Sysadmins build a new server, the sshd keys should be backedup and fingerprint information recorded for future reference. From a console session on the newly build machine, backup the sshd key data usually located at /etc/ssh/ssh_host_*. Simply make sure the data is backed up to a secure location. The key to this step is to restore these keys if you ever need to rebuild the server. If you don't, then you're encouraging your users to blindly accept a new and unknown server key!

Fingerprint data can be recorded by the command "find /etc/ssh/*.pub -exec ssh-keygen -lf {} \;", which will output something like:
[jtosh@primus ssh]$ find /etc/ssh/*.pub -exec ssh-keygen -lf {} \;
1024 3f:4a:c2:f1:bc:ad:73:08:c8:a2:11:07:60:32:26:a7 ssh_host_dsa_key.pub (DSA)
2048 86:07:13:98:d8:2d:26:24:63:77:80:03:d7:ca:dd:2b ssh_host_key.pub (RSA1)
2048 a3:05:84:91:2e:d1:a0:f2:c3:1a:9a:09:d6:77:16:34 ssh_host_rsa_key.pub (RSA)
[jtosh@primus ssh]$


A responsible admin will make this fingerprint data available to their users in an easy to access medium such as an intranet site or support FAQ.

To make live easy for your users, you might even gather the data in a format that can be automatically imported to their ~/.ssh/known_hosts file with this command: "ssh-keyscan hostname". The output will look like the data you normally see in your known_hosts file:

primus ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCvFnTOj3NyxxD798We9l3HIQGdV/jnqI1nIXjTSnyq45DXRRRgJ1RizwHOaoJVjUlVgvLLfGFA8VR9n2hgOR4b6njmPY9Uw9XR7cqMl/K5OgaIVJ6hbfk5ica+COCK0udmpaMA6Dg3AX4BOqs6UoD2h4GtEOKPGHj5IXRk6T2Zf2eB2tKgJOIeBYXy9sF1jJ4NpW5tQPkqc4DH2HTR7nk/7SLR2N4pSwFanDAjs2END5n6luzW8mofCIzq/t36ZG86N8F2MgAjtQlmFs/7KCaV5JeNFbpXcVZvBPfC5kfAk047bmBfDJWZKZviLOsATSCDA+cIPwx2fhKl5WfY2Wcb


Note, while this command can be ran remotely, for this purpose, it should be run locally from the console immediately after the server is brought online.

Append this data to the end of the file where you keep all your other server public keys so that your users can import everything all at once (or you can put it there for them).

Users: Your job should be easy if your admins have done their due diligence with their server keys. However, if you do need to blindly accept a server's signature, there is something you can do to immediately attempt to validate your decision... When prompted to accept the warning of unknown keys, go ahead and accept the fingerprint. Once you get logged into the hopefully not-compromised server, even if it's through a man in the middle, issue the earlier command "find /etc/ssh/*.pub -exec ssh-keygen -lf {} \;" and verify the fingerprint against what you just accepted. If they are different, then you've just found yourself at the wrong end of a MITM attack. It's not a perfect solution because of rootkits and the ability of the MITM to alter what you're seeing, but at least you've just added a tool and some understanding to your own bag of tricks.