While working on a deployment process that automatically updated an ElasticIP to point to a new instance, I got to see a lot of these:
Offending key in /Users/lhn/.ssh/known_hosts:45 RSA host key for xxx.yyy.zzz has changed and you have requested strict checking. Host key verification failed.
Here is a sed one-liner to delete offending key (on line 45 in this case) from SSH’s known_hosts file. This is a reasonable thing to do when you know why the host key has changed and don’t expect it to do so very often.
sed -i -e '45d' ~/.ssh/known_hosts
-i is for in-place editing and -e provides the expression, which is to delete line 45.
However, sometimes you expect the host key to change frequently and a better approach to not check or store the host key in the first place. That can be achieved as follows (kudos Peter Leung)
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@some.host
This tells SSH to use always-empty /dev/null as its place to record host keys and to not complain when connecting to host with an unknown key. Thus no host keys are stored or checked.
At the risk of stating the obvious, this does of course side-step SSH’s ability to protect you from man-in-the-middle attacks.