What is the best method for adding RSA Key Fingerprints to known_hosts upon provisioning each server?

Inquisitive asked:

This question was inspired by this thread

The hypothetical scenario, for context is as follows:

  1. SSH servers, whether they be routers, firewalls etc. are all firstly provisioned within a private + secure environment before being deployed. The SSH keys are generated locally on the server in this environment.
  2. The SSH servers have their own ACLs in place for refusing connections from anything but our hosts
  3. The host machine will be a Linux machine with multiple users

The standard approach may be to employ PKI with a trusted CA installed on all user accounts, and deploy a local SCEP server etc. But in place of this, would it be prudent to:

  1. While in the secure environment, and upon provisioning, import the RSA fingerprint of the server to the known_hosts container of our host machine (or wherever it would be stored, I’m not overly familiar with Linux yet) using ssh-keyscan -H x.x.x.x >> ~/.ssh/known_hosts

  2. Share/mirror that container of RSA fingerprints across the users on that host machine

  3. Configure the host/each user to reject/drop/refuse the connection when given the following prompt, so that

The authenticity of host '[hostname] ([IP address])' can't be established. RSA key fingerprint is [key fingerprint]. Are you sure you want to continue connecting (yes/no)?

  1. They cannot connect to any server that hasn’t gone through this procedure, then
  2. Perhaps create a sandboxed separate user for cases where these aforementioned processes + restrictions cannot be implemented, but where remote configuration is still needed, so that the main more commonly-used passwords are not compromised by a possibly fake SSH server.

My answer:


Have you got an internal DNS server? Put the host public keys in SSHFP records. Now they are available throughout your organization without needing to be copied manually everywhere. Client machines will need to be configured with VerifyHostKeyDNS yes to check them. Something like this in /etc/ssh/ssh_config:

Match host *.internal.example.com
    VerifyHostKeyDNS yes

To prevent connections to unknown hosts, use StrictHostKeyChecking yes. But be aware that it is very common to need to connect to new hosts, so this is likely to introduce enough inconvenience to cause users to try to bypass it. See the man page for alternate configurations that might strike a better balance.


View the full question and any other answers on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.