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 -R
ipAddress
- (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?
The great feature
HostKeyAlias
solves your problem:creates an entry
hostkeyalias__vm_2013-05-11_07
(without IP) inknown_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:and change
$HOSTKEYALIAS
whenever the VM is changed. From time to time the old entries should be deleted fromknown_hosts
.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.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:
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
: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 forssh 192.168.1.53
: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.create
~/.ssh/config
with the contents:Alternately, you can create an alias for ssh to:
You could retrieve the new host key from the VM console and update the known hosts file after an instance boots up.