The SSH option StrictHostKeyChecking is a security feature that affects how SSH verifies the identity of a remote computer when connecting to it.
When this option is enabled, the client will automatically reject any key from the server that does not match the one stored in its known_hosts file.
This helps protect against man-in-the-middle attacks, where an attacker may attempt to impersonate the server by providing a different hostkey.
This option is enabled by default.
Table of Contents
How StrictHostKeyChecking works in SSH?
When we connect to a host for the first time, keys are exchanged between the client and the host, and the server identifies itself with the keys that are used. If they’re accepted, they will be stored in the .ssh/known_hosts file at the user’s home.
If the remote host key is changed, a warning will be printed on the ssh client’s terminal and the connection will be refused, but when we set StrictHostKeyChecking to no, we will accept any key that’s sent by the server, which might be useful if we’re using a test system that gets redeployed frequently (and thus, generating a new host key).
It is not recommended to be used in general, since it protects us from a server being replaced and also someone impersonating the server we want to connect to with a server that, for example, logs usernames and passwords to access our system later.
Errors related to StrictHostKeyChecking
If the server host key is in the known_hosts file:
- ssh user@host: no prompt & no error (because host is in known_hosts)
- ssh -o StrictHostKeyChecking=no user@host: no prompt & no error
If the server host key is not in the known_hosts file:
- ssh user@host: prompt & display error Host key verification failed.
- ssh -o StrictHostKeyChecking=no user@host: no prompt & no error & add new key to known_hosts file
Best practice for StrictHostKeyChecking in SSH
It is typically recommended that you keep StrictHostKeyChecking enabled in your SSH configuration since it provides an extra layer of security against man-in-the-middle attacks.
If you need to disable it for a specific purpose or situation, such as when connecting to a test system that gets redeployed frequently, you should consider setting up a separate SSH configuration for that situation. This way, you can ensure that other connections are protected by the default settings.
Ultimately, it’s always best to keep StrictHostKeyChecking enabled unless absolutely necessary.
How to disable StrictHostKeyChecking in SSH?
You can disable it in the command line like this.
ssh -o StrictHostKeyChecking=no user@hostname
This will disable StrictHostKeyChecking for this session.
You can disable it for a specific host in SSH configuration file(usually located in ~/.ssh/config).
You can also disable it permanently by adding this line to your SSH configuration file :
This will disable StrictHostKeyChecking for all the hosts.
However, it should not be used in production environments due to the potential security risks.
StrictHostKeyChecking is a useful option to help protect against man-in-the-middle attacks and make sure that your SSH connection is secure.
Thanks for reading this tutorial! We hope it helped you understand the SSH option StrictHostKeyChecking and how to disable it on your system. If you have any questions, feel free to leave them in the comments below.