Linux / Unix: Disable OpenSSH Host Key Checking

Posted on in Categories last updated December 30, 2011

I‘ve a remote Unix server running with OpenSSH remote login service. The openssh is configured for passwordless login using ssh keys. Our ISP allows to boot all Linux servers into the rescue mode. It allow us to bring a server online remotely in order to troubleshoot system problems that would normally only be resolved by an OS Reload (such as accidentally deleting files or wrong firewall configurations blocking ssh access). When server boots into a remote rescue mode I can connect using SSH. They SSH keys will not be the same in the rescue mode so I get key mismatch messages as SSH keys are re-generated on each boot:

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
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:1
RSA host key for has changed and you have requested strict checking.
Host key verification failed.

How do I ignore OpenSSH hos key checking from my Apple OS X laptop while login using the ssh?

The UserKnownHostsFile option defines a file to use for the user host key database instead of the default ~/.ssh/known_hosts. You can set this to /dev/null. The StrictHostKeyChecking must be set to no”, so that ssh will automatically add new host keys to the user known hosts files. If this flag is set to “ask”, new host keys will be added to the user known host files only after the user has confirmed that is what they really want to do, and ssh will refuse to connect to hosts whose host key has changed. The host keys of known hosts will be verified automatically in all cases. The argument must be “yes”, “no” or “ask”. The default is set to “ask”. The syntax is as follows:

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
ssh -o UserKnownHostsFile=/dev/null,StrictHostKeyChecking=no
WARNING! These examples demonstrates a pretty serious security issues. I strongly suggests that you use the ssh-keygen command to get rid of this problem in secure manner.

You can define the bash shell alias as follows:

alias newssh='ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'

You can use the command as follows:


A Note About rsync Command

The syntax is as follows:

rsync -e 'ssh -o UserKnownHostsFile=/dev/null,StrictHostKeyChecking=no' -avr filename
rsync -e 'ssh -o UserKnownHostsFile=/dev/null,StrictHostKeyChecking=no' -avr /path/to/src

As I said earlier this could lead into a security issue, so pass the -R option to ssh-keygen command to removes all keys belonging to hostname from a known_hosts file. This option is useful to delete hashed hosts. If your remote hostname is, enter:
$ host
$ ssh-keygen -R
$ ssh-keygen -R

Note: You need to replace the and with actual host name and IP address.

4 comment

  1. You could also uncomment the StrictHostKeyChecking in your respective ssh_config file and change the value from ask to no and it will auto populate any new values to your known_hosts file.

  2. delete your ssh key file…

    rm $HOME/.ssh/known_hosts

    (to permanently fix this…. and also force you to review and accept keys every time)
    ln -s /home/$USER/.ssh/known_hosts /dev/null

    put your key in the garbage and reconnect. symlink puts any new keys in the garbage by default.

Leave a Comment