17

Each user creates and destroys 15+ VM's per day. The VM's are created in the company's internal OpenStack cloud.

Every time a new vm is assigned an ip address which has previously been handed out, the user gets the dreaded host key verification failed error. This is because the ssh key does not match the IP address in the users known_hosts file.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
xxxxxxxxxxx
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:4
RSA host key for domain.com has changed and you have requested strict checking.
Host key verification failed.

The two solutions I can see are:

  • Turn off strict checking - (Security risk)
  • Have the users run ssh-keygen -RipAddress - (users are getting tired of this solution, since then run into it multiple times per day)

Is there any way to prevent this error message, yet stay secure? perhaps turn off security checking for just a specific subnet?

chicks
  • 3,639
  • 10
  • 26
  • 36
spuder
  • 1,695
  • 2
  • 25
  • 42
  • possible duplicate of [How to remove strict RSA key checking in SSH and what's the problem here?](http://serverfault.com/questions/6233/how-to-remove-strict-rsa-key-checking-in-ssh-and-whats-the-problem-here) – Michael Hampton May 10 '13 at 23:07
  • 1
    @MichaelHampton This is no duplicate; this question is much broader. The other one was about solving the problem for a single key. This is about handling frequent key changes. – Hauke Laging May 10 '13 at 23:12
  • 2
    ...any reason you can't use Puppet or something equivalent to put a standard per-user key on each VM? – voretaq7 May 11 '13 at 01:24

4 Answers4

21

The great feature HostKeyAlias solves your problem:

ssh -o HostKeyAlias=hostkeyalias__vm_2013-05-11_07 user@host

creates an entry hostkeyalias__vm_2013-05-11_07 (without IP) in known_hosts. Of course, you could write a script or shell function which sets this value before each ssh call. Or you use a shell variable:

HOSTKEYALIAS=hostkeyalias__vm_2013-05-11_07
ssh -o HostKeyAlias=$HOSTKEYALIAS user@host

and change $HOSTKEYALIAS whenever the VM is changed. From time to time the old entries should be deleted from known_hosts.

Hauke Laging
  • 5,157
  • 2
  • 23
  • 40
15

The problem is that ssh presumes a 1-to-1 mapping between IP addresses and hosts. We need to break that mapping only for the IP addresses of your cloud servers.

The Solution

Add the following stanza to your ~/.ssh/config file.

# Disable HostKey checking for servers which frequently change keys
Host 172.16.24.32  172.16.24.33  172.16.24.34
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking no

Just change the IP addresses and you are done.¹

Optional: An alternative for IP address ranges

If you'd like to apply this to a netblock, such as 192.168/16, you can use wildcards like so:

# Do not keep HostKeys for internal networks.
Host 10.*.*.*  192.168.*.*
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking no

Optional: Using hostnames

The original question mentioned IP addresses, but you can, of course, use hostnames instead. For example, this would match ssh instance32.vm.yoyodyne.com:

Host *.vm.yoyodyne.com
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking no

If you want to use both hostnames and IP addresses, you'll need to explicitly specify both as SSH does not match on the resolved IP address. For example, if you have ssh ourvm.local as a shortcut for ssh 192.168.1.53:

Host 192.168.1.53  ourvm.local
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking no

Caveat

Be cautious when circumventing ssh's security model. In particular, double check that your wildcards do not match any genuine servers whose HostKeys will not be changing.


¹ Why /dev/null? I'm throwing the KnownHosts data into the bit bucket because only setting StrictHostChecking no removes the warning, but still refuses to connect. This is silly, so I presume OpenSSH will eventually change the behavior or add a new option. If and when a better solution comes around, I'll update this answer.

hackerb9
  • 251
  • 2
  • 4
  • 2
    By the way, while this would "solve" the problem of SSH getting confused by dynamic IP addresses and thinking HostKeys have changed when they haven't, it is not the right solution. A better way would be to use mDNS and tell ssh to store only the hostname, not the IP address. Under `Host *.local` set `CheckHostIp no`. – hackerb9 Jan 29 '19 at 18:57
  • 1
    Oh this is awesome. Host checking for private IP address ranges is madness when you work with new devices all the time. For me, I had to use `Host 10.*.*.* 192.168.*.*` instead of `Host 10.?.?.? 192.168.?.?`. I didn't investigate why. – Heath Raftery Dec 20 '19 at 03:21
  • Thanks, Heath. I had read the man page for ssh_config too quickly and had seen the one example of matching IP addresses had used a question mark. An asterisk is correct. – hackerb9 Dec 21 '19 at 22:41
  • This is super awesome. I'm working on some Raspberry Pi projects, using a single RasPi with multiple different SD cards. Each time I switch SD cards I had to do the stupid ssh-keygen thing (the RasPi is getting the same IP each time because it's the same MAC address naturally) – fdmillion Jan 15 '21 at 04:51
11

create ~/.ssh/config with the contents:

Host *
    StrictHostKeyChecking no

Alternately, you can create an alias for ssh to:

ssh -o StrictHostKeyChecking=no
Douglas Land
  • 170
  • 5
  • 1
    This does not answer the question. The OP knows about StrictHostKeyChecking per his post. He is asking about various methods to achieve a certain outcome, one of which is modifying the value of StrictHostKeyChecking. – 0xSheepdog Aug 31 '17 at 15:49
0

You could retrieve the new host key from the VM console and update the known hosts file after an instance boots up.

Lorin Hochstein
  • 4,868
  • 15
  • 54
  • 72