HowTo: Disable SSH Host Key Checking

By default, the SSH client verifies the identity of the host to which it connects.

If the remote host key is unknown to your SSH client, you would be asked to accept it by typing “yes” or “no”.

This could cause a trouble when running from script that automatically connects to a remote host over SSH protocol.

Cool Tip: Slow SSH login? Password prompt takes too long? You can easily remove the delay! Read more →

This article explains how to bypass this verification step by disabling host key checking.

The Authenticity Of Host Can’t Be Established

When you log into a remote host that you have never connected before, the remote host key is most likely unknown to your SSH client, and you would be asked to confirm its fingerprint:

The authenticity of host ***** can't be established.
RSA key fingerprint is *****.
Are you sure you want to continue connecting (yes/no)?

If your answer is ‘yes’, the SSH client continues login, and stores the host key locally in the file ~/.ssh/known_hosts.

If your answer is ‘no’, the connection will be terminated.

If you would like to bypass this verification step, you can set the “StrictHostKeyChecking” option to “no” on the command line:

$ ssh -o "StrictHostKeyChecking=no" user@host

This option disables the prompt and automatically adds the host key to the ~/.ssh/known_hosts file.

Remote Host Identification Has Changed

However, even with “StrictHostKeyChecking=no“, you may be refused to connect with the following warning message:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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
*****
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.

If you are sure that it is harmless and the remote host key has been changed in a legitimate way, you can skip the host key checking by sending the key to a null known_hosts file:

$ ssh -o "UserKnownHostsFile=/dev/null" -o "StrictHostKeyChecking=no" user@host

You can also set these options permanently in ~/.ssh/config (for the current user) or in /etc/ssh/ssh_config (for all users).

Cool Tip: Log in to a remote Linux server without entering password! Set up password-less SSH login! Read more →

Also the option can be set either for the all hosts or for a given set of IP addresses.

Disable SSH host key checking for all hosts

Host *
   StrictHostKeyChecking no
   UserKnownHostsFile=/dev/null

Disable SSH host key checking For 192.168.0.0/24

Host 192.168.0.*
   StrictHostKeyChecking no
   UserKnownHostsFile=/dev/null
Was it useful? Share this post with the world!

21 Replies to “HowTo: Disable SSH Host Key Checking”

  1. Exactly what I needed. Thx for posting.

  2. Well explained.

  3. I was looking for a way to disable host checking from Python’s pexpect. -o “UserKnownHostsFile=/dev/null” did the job. Thank you.

  4. Feels like it’s a little irresponsible to tell people to do this without warning them of the dangers of doing so…

  5. Thanks!

  6. Thanks for this post, is exactly what I need.

  7. Note: It is one thing to do this to allow a local IP address such as above 192.168.x.x but it risky to do with a remote host etc.. I would probably just edit ~/.ssh/known_hosts or wipe the file and start over if I am seeing the messages above.

  8. Thanks

  9. I was having big issues trying to backup to 2 nas drives that were swapped out daily which were on the same ip.

    This fixed my problem nicely. Many thanks

  10. Thanks for this little HowTo 🙂
    Should anybody drop by using Windows you can use NUL instead of /dev/null, like UserKnownHostsFile=NUL for dropping any new hosts.

    1. It creates file named NUL I can’t delete… 🙁

      1. Hey Szymon,

        Try using the following command in your command prompt:

        rm NUL

        If anyone runs else runs into this issue, just use whichever string you pointed UserKnownHostsFile towards. For example, if you wrote “UserKnownHostsFile=NULL”, it would be:

        rm NULL

        I reckon this is just a temporary variable you’re populating with the contents of what would normally be written to your known_hosts file.

        The command removes/depopulates the variable, if I’m not mistaken (on Linux I would just overwrite the variable to be blank but that doesn’t seem to work for me in Windows), after which you can establish the connection without issues.

        I guess rebooting the machine would also work, but that’s a bit of a hassle compared to this method.

        Just happened to run into your comment while I was looking into this myself and that’s when I connected the dots.
        Hope it still helps you or anyone else out!

        P.S.: if any Windows-savvy folks know of a more efficient way to do this, I’m all ears!

  11. One more suggesting for scripting. In order to reduce noisiness add
    -o “LogLevel=ERROR”
    This will eliminate repeated messages like “Warning: Permanently added ‘123.123.123.123’ (ECDSA) to the list of known hosts.”

  12. !!!Warning!!! In the config file, entering the IP address of a host and then connecting via a hostname doesn’t seem to work (for me on Linux Mint 20). The “Host” heading must textually match the ‘host’ used in the ssh command.
    i.e.
    > cat ~/.ssh/config
    Host 127.0.0.1
    options
    > ssh user@localhost
    does not work.

  13. Thank you. I manage a lab environment where hosts are frequently reimaged and this has been a thorn in my side.

  14. Thank for share.

  15. Hi,
    We just recently set up a password-less connection between two servers. The question put to me by management related to the contents of the knonw_hosts file. Basically their concern was if some one were to gain access to our system, and they were able to read the know_hosts file, they would get the IP address information to the rest of the servers linked to this box. I see your solution will by-pass the know_hosts checking and get you without being prompted.
    My question is on the following statement:
    “you can skip the host key checking by sending the key to a null known_hosts file:
    $ ssh -o “UserKnownHostsFile=/dev/null” -o “StrictHostKeyChecking=no” user@host”
    When you implement this, does the IP address of the server you’re connecting to still go to the existing .ssh/known_hosts file or does it not get stored anywhere?
    (i.e. “UserKnownHostsFile=/dev/null”)
    It looks like it doesn’t get stored and that would be the solution to my issue however, I need to be sure. Please confirm this. Thanks!

    1. Friend, if you just take this test yourself, you’ll know the answer right away.
      In this particular case you don’t have to wait for days or weeks for someone to test this and post the answer here so you know the answer.
      Run the command now:
      ssh -o “UserKnownHostsFile=/dev/null” -o “StrictHostKeyChecking=no” user@host
      And then check the contents of the x.txt file.
      Don’t be afraid, the result of this command can be undone easily.
      Just test it now and find out now 😉
      Peace \o/

  16. Thanks for posting, works perfectly well!

    1. You are welcome:)

Leave a Reply