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?

Improve this question
1
  • 1
    You can pray there's no MiTM on the first connection, like everyone else does.
    – Neil Smithline
    Commented Nov 8, 2015 at 18:50

2 Answers 2

Reset to default
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.
Improve this answer
1
  • 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 and here.
    – Seldom 'Where's Monica' Needy
    Commented Apr 28, 2016 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.

Improve this answer
2
  • 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
    Commented Nov 8, 2015 at 8:48
  • Links to more information about working through DNS in above comment.
    – Seldom 'Where's Monica' Needy
    Commented Apr 28, 2016 at 19:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .