This question was inspired by this thread
The hypothetical scenario, for context is as follows:
- 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.
- The SSH servers have their own ACLs in place for refusing connections from anything but our hosts
- 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:
While in the secure environment, and upon provisioning, import the RSA fingerprint of the server to the
known_hostscontainer 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
Share/mirror that container of RSA fingerprints across the users on that host machine
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)?
- They cannot connect to any server that hasn’t gone through this procedure, then
- 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.
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
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.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.