0

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.
Inquisitive
  • 103
  • 2

1 Answers1

0

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.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • Thank you for the helpful response! || Yes in this scenario we would have an internal DNS server. || This sounds like it would be sufficient in this scenario. DNS Cache Poisoning wouldn't be an issue, since the records are installed, not cached. || The only issue would be in the case of a route hijack - but we're sufficiently protected against that with prefix filters and the like. If these were servers were out in the wild internet, and not within our AS, then Certificates would need to be used. || Does that all sound correct? – Inquisitive Jan 19 '21 at 06:28
  • Sounds reasonable to me. – Michael Hampton Jan 19 '21 at 06:36