3

I am frequently rebuilding servers for staging and development. I connect to them with SSH for provisioning.

In the process, I'll destroy a VM, rebuild it, and provision it all over again with the new scripting.

One small issue I have is that my local machine remembers the old host key and warns me that it's changed for the hostname or IP after it's been rebuilt.

This is expected and a good thing. But irritating.

I then have to ssh-keygen -R the local fingerprint and try to connect again to get prompted to accept a new one.

This is tedious. So I looked and learned that I can set some ssh options like ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

That fixes my workflow issue, but made me wonder how secure the whole process is in the first place.

If I just blindly accept every fingerprint that a new server sends me, am I only minimizing the Man in the Middle attack potential by blindly trusting it only once and then expecting it to be the same from there forward?

Or, other than getting the server keys through another channel before connecting the first time, is there some way to close that hole and know that the fingerprint I'm getting is actually from the server I intend?

Julian
  • 516
  • 6
  • 18
shanemgrey
  • 153
  • 5

2 Answers2

3

A couple of possibilities:

  • Backup and restore the keys. I use a script to backup both public and private keys in an encrypted archive (tar.bz2) file to a local server over rsync.
  • Use a set of private keys and reuse them across systems - probably not a good idea unless the area is secure and the chances of MITM are slim.
  • Use keys signed by a trusted certificate (e.g. https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu)
  • Finally, you could use a key management system or even a script to pull the key fingerprints from a central server before attempting to connect. I never tried it myself, but I do have a script-override to deal with some other SSH stuff. Instead of using SSH directly, I use this aliased script to connect to target host.
Vasu
  • 56
  • 2
  • As mentioned below, SSHFP-records being added to DNS have gained some popularity, as this prevents attackers from MITMing unless they have control over DNS in addition to being able to impersonate a server you're trying to connect to, which should be difficult, especially in zones where DNSSEC has been set up. The best introductions/guides I've found for SSHFP-over-DNS come from [here](http://www.phcomp.co.uk/Tutorials/Unix-And-Linux/ssh-check-server-fingerprint.html) and [here](http://jpmens.net/2012/07/27/verifyhostkeydns-yessssss/). – Seldom 'Where's Monica' Needy Apr 28 '16 at 18:58
0

In addition to the other answer, there is a special type of DNS record that can store the SSH host fingerprint so that the provided key can be checked against the one in the DNS record (possibly using DNSSEC). I do not know much about this, but there should be an openssh client setting for this.

multithr3at3d
  • 12,355
  • 3
  • 29
  • 42
  • 1
    The openssh setting is VerifyHostKeyDNS, which you can set to ask so that it still prompts you but tells you the results of DNS validation, or yes if you want to connect immediately if DNS validation succeeds. – user2313067 Nov 08 '15 at 08:48
  • Links to more information about working through DNS in [above comment](http://security.stackexchange.com/questions/104932/how-do-i-know-a-new-host-key-is-safe-to-accept?rq=1#comment223237_104936). – Seldom 'Where's Monica' Needy Apr 28 '16 at 19:02