I have some cloud boxes that change their IP frequently.

I ssh using the hostname but have to edit the known_hosts file every time the server launches because of this error message:

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…

Aside from any security risks and such that are associated with what I want to do, is there a way to either ignore this error or overwrite the known_hosts file automatically such that I don't always have to edit it myself?


7 Answers 7


Edit your .ssh/config file and add a config for this server:

Host frequent-rotation.example.com
    CheckHostIP no

CheckHostIP defaults to 'yes'. What this does is to do just the kind of check you're failing. Turning it off means it just trusts that the IP is variable, and will to key-checking against the hostname.

  • 8
    This disables a security feature for all servers you will ever connect to, which is extremely bad practice. You should instead use this option only for a specific host you know will have this problem - or use the HostKeyAlias option - again for a specific host.
    – zaTricky
    Feb 5, 2018 at 8:34
  • @zaTricky "Extremely bad practice"? What's so extreme about it hmm? I think it's about as much secure, it's simply an individual preference. You just pin a key to a hostname (instead of IP). For https, the HPKP works similarly and everybody says it's either secure or overly secure.
    – kubanczyk
    Feb 5, 2018 at 8:49
  • @kubanczyk This is saying to make it a global setting - no advice regarding specifying a host, which I did point out
    – zaTricky
    Feb 5, 2018 at 11:22
  • 3
    It's better to use this setting on a per-host basis. So edit ~/.ssh/config and add Host hostname then under that line put CheckHostIP no. That way it only affects that host instead of operating globally. Apparently lots of people want to point this out but can't edit the original post (edit queue is full; eh).
    – CR.
    Jun 17, 2021 at 1:14
  • 1
    I see the answer has been edited to take the suggestions into account. :-)
    – zaTricky
    May 3, 2022 at 9:00

Addition: you could try only disabling the CheckHostIP check for that name:

Host *
  [ global settings .. ]

Host very.dynamic.host
  CheckHostIP no
  • 7
    This is the best option to reduce the security impact of disabling IP-checking.
    – Espo
    Oct 22, 2010 at 12:58

A lot of the answers here will work - but technically they're workarounds. OpenSSH already has a built-in feature with this in mind: HostKeyAlias.

In your .ssh/config file, add HostKeyAlias <alias> to a host configuration:

host myserver.example.com
HostKeyAlias myserver.example.com

With this in place, connecting to server myserver.example.com will not use the hostname or the IP address for the local reference - it will always only use the given HostKeyAlias when connecting to that server. For me it makes sense to use the hostname - but you can of course use any alias you like.

Typical configs for myself for dynamic hosts are like so:

host myserver
hostname myserver.dyn.example.com
HostKeyAlias myserver.private.example.com

This can also be used in some obscure scenarios where you know a bunch of your servers have the same host keys (generally this should not be the case). This would then prevent duplicate entries. In future, if the keys legitimately change, you don't have to replace/delete multiple entries. Only one. Gitlab Geo servers are a good example of this.

Regarding clearing the known_hosts file, I would suggest looking at other questions/answers specifically related to maintaining/removing stale known_hosts entries. For example, see https://serverfault.com/questions/29262/how-to-manage-my-ssh-known-hosts-file ; I'm especially impressed by user1953828's answer, though I see it doesn't have many upvotes (yet). :)

  • 6
    This goes to show how much value a same-day answer has on SO vs the right answer, answered 8 years later.
    – parity3
    Jan 4, 2019 at 2:15

I use these dodgy options to work around this problem. (My host's public key is regenerated quite often. so this removes the IP and Key check)

ssh remoteServerName -l username -o "UserKnownHostsFile=/dev/null"

You can also just use this if the Key stays the same but the IP changes:

ssh remoteServerName -l username -o "CheckHostIP=no"
  • 2
    If your server changes host keys that often, you should consider setting up host-key signing Oct 1, 2019 at 22:14

You could put CheckHostIP no into your ~/.ssh/config file, but that leaves you open to spoofing attacks. If you're not concerned about that, then this setting should turn off the known_hosts check.


You can set StrictHostKeyChecking=no in your ssh client configuration (i.e. The ~/ssh/config file on the machine that you connect from), to ignore the warning.


I avoid adding the fingerprints to my known_hosts file when connecting to transient AWS machines. I use a command such as

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i secret.pem [email protected]

to connect to them. It will not ask you if you want to add the machine “to the list of known hosts.” Replace by the IP address of your machine and secret.pem by the full path of your Ssh key. You will still get a warnings that the has been added, but it has really vanished into /dev/null. I do this often enough that I set an alias in my ~/.profile

alias awsssh='ssh -i secret.pem -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'

I reserve ssh [email protected] type commands for machines were I went to the trouble of checking the fingerprint.

  • 1
    This makes sense for servers you only ever connect to once - but there are better ways to get rid of stale entries - and you shouldn't be that concerned about how dirty your known_hosts file is. Likely you've spent far more time and energy creating that alias than value the alias has brought you.
    – zaTricky
    Feb 5, 2018 at 8:31

You must log in to answer this question.

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