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 peter@192.168.0.100

I am insist to use only this syntax as

 ssh xxx.xxx.xxx.xxx 

for connection

1
  • 14
    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. Feb 10 '15 at 7:05
5

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 Feb 10 '15 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
    Feb 10 '15 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. Apr 3 '20 at 15:47
3

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
    Apr 3 '20 at 19:35
  • @l0b0 Fair enough your honor !
    – Archemar
    Apr 4 '20 at 7:33
1

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.