0

Is it possible to prevent the following message about: ( REMOTE HOST IDENTIFICATION HAS CHANGED )

When using only this connection syntax

 ssh xxx.xxx.xxx.xxx

example of warning message:

 ssh  10.19.11.1
 CentOS release 5.8 (Final)
 Kernel 2.6.18-308.el5 on an i686
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 @ 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
 dd:6f:32:8f:8f:8c:70:9c:95:f1:48:83:60:97:cc:ed.
 Please contact your system administrator.
 Add correct host key in /root/.ssh/known_hosts to get rid of this message.
 Offending key in /root/.ssh/known_hosts:7
 RSA host key for 10.19.11.1 has changed and you have requested strict checkin.
 Host key verification failed.

each time I get these message , then I clean the /root/.ssh/known_hosts

as

     cp /dev/null /root/.ssh/known_hosts

I also was thinking to set the command cp /dev/null /root/.ssh/known_hosts in the crontab ,

so every day at 24:00 it clean the known_hosts file ( this solution decrease this problem but not solved it )

so this solution isn’t so good solution because user can get the warning message in spite we clean the known_hosts file evry day

maybe we can do something on /etc/ssh/ssh_config file in order to prevent the SSH host key checking?

remark:

I don’t want to use the following method in order to prevent the SSH host key checking ( because I use reflection/putty )

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected]

I am insist to use only this syntax as

 ssh xxx.xxx.xxx.xxx 

for connection

5
  • 15
    Simply put: don't do it. Did you actually read that warning at all? There is a reason for this warning. And it is to protect you from harm of a MitM attack and other bad things. Commented Feb 10, 2015 at 7:05
  • @0xC0000022L Is it the same risky if you try to login to (a docker contaier) at 127.0.0.1?
    – Kuchara
    Commented Sep 11, 2023 at 11:07
  • @Kuchara I'd say it still depends, but the risk is of course limited. If you can trust this container, e.g. because you yourself built the image, then this could work. However, in that case you may want (and are able) to "discover" the public host key by different means and therefore don't have to trust any value either. But the risk seems reduced in this scenario, I agree. Commented Sep 11, 2023 at 20:21
  • 1
    @0xC0000022L My concern is if there is an option to spoof 127.0.0.1 IP address somehow? But I've just found this option that works flawlessly for 127.0.0.1: NoHostAuthenticationForLocalhost=yes
    – Kuchara
    Commented Sep 12, 2023 at 8:29
  • @Kuchara I think spoofing is of little concern in this case. These address ranges (it's not just 127.0.0.1) receive special treatment. Commented Sep 12, 2023 at 8:42

4 Answers 4

7

When connecting to throwaway virtual machines or such, you should better not store the keys in the first place.

Create a ssh0 alias or function with the following content:

alias ssh0='ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=ERROR'

In this way, you won't pollute your ~/.known_hosts file with garbage, and since you're using a different command, there would be a psychological boundary between the "real" ssh and the one used to instrument some local widget.

Another useful alias is

alias sshy='ssh -o CheckHostIP=no'

for when you're connecting to a device which changes its IP frequently, as eg. a home router to which the ISP assigns a different IP each time it's power-cycled.

1
  • Perfect answer to this! Commented Feb 1, 2021 at 19:00
6

Update: Nowadays you can use SSH certificates, similar to TLS certificates. Then you can add a known_hosts entry to trust the certificate rather than the individual keys, and you'll never get this message again.


Heed @0xC0000022L's warning!

If you know the host key has changed, you can remove that specific entry from the known_hosts file:

ssh-keygen -R xxx.xxx.xxx.xxx

This is much better than overwriting the full hosts file (which can be done with just > /root/.ssh/known_hosts).

If you don't want to use ssh command-line options, I believe the only other way to do this would be to modify the SSH code and recompile. Which you really don't want to do!

3
  • but I want to do this by automatic way , when user complain about this , I don’t want to do it manual Commented Feb 10, 2015 at 8:00
  • You don't want to do it manually (removing known_hosts entries), and you don't want to do it automatically (using ssh options). How do you want to do it then?
    – l0b0
    Commented Feb 10, 2015 at 8:05
  • @l0b0 By giving a command-line option to suppress the feature. In some environments, such as virtual machine environments and other very dynamic configurations (especially test environments), these host keys change frequently and because they are on an isolated network, there is little security to gain by doing the check. Having to do an ssh-keygen -R every time is annoying. I suppose one could write a shell for ssh, a shell script that parses the destination address and pre-removes the key before passing options to ssh, but this seems like overkill. Commented Apr 3, 2020 at 15:47
2

step 1 : remove faulty key

 ssh-keygen -R 192.168.1.1

step 2 : add new key

 ssh-keyscan 192.168.1.1 >> ~/.ssh/known_hosts

or depending on your situation

 > ~/.ssh/known_hosts
ssh-keyscan 192.168.1.1 192.168.1.2 ... >> ~/.ssh/known_hosts
2
  • 1
    -1 for providing a footgun without a warning.
    – l0b0
    Commented Apr 3, 2020 at 19:35
  • @l0b0 Fair enough your honor !
    – Archemar
    Commented Apr 4, 2020 at 7:33
2

If only for connecting to 127.0.0.1 (localhost) matters, then this ssh option should work:

-o NoHostAuthenticationForLocalhost=yes

This option has existed since at least OpenSSH 3.7 (from 2003).

You must log in to answer this question.

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