What is StrictHostKeyChecking in Ubuntu SSH

This article explains the purpose and functionality of the StrictHostKeyChecking option in the Ubuntu Linux SSH client configuration. You will learn how this security feature prevents man-in-the-middle attacks, how its different settings (ask, yes, accept-new, and no) behave, and how to safely configure it for your environment.

What is StrictHostKeyChecking?

When you connect to a remote server via SSH for the first time, the server sends its unique public key (host key) to your Ubuntu client. The StrictHostKeyChecking option determines how your SSH client responds to this key, specifically whether it will automatically trust the key, prompt you for verification, or reject the connection if the key is unrecognized or has changed.

This setting is a crucial defense against Man-in-the-Middle (MITM) attacks, where an attacker intercepts your connection and impersonates the destination server.

Configuration File Locations

In Ubuntu, this option can be configured globally or for individual users:

You can also override this setting on a per-command basis using the -o flag:

ssh -o StrictHostKeyChecking=yes user@server_ip

The Four Configuration Options

The StrictHostKeyChecking parameter accepts one of four values, each offering a different balance of security and convenience:

1. ask (Default)

This is the default behavior of the OpenSSH client. * New Host: The client prompts you with a message asking if you want to trust the new key. If you type “yes”, the key is saved to your ~/.ssh/known_hosts file, and you are connected. * Changed Key: If the server’s key has changed since your last connection, the client will refuse the connection and show a warning, as this could indicate an ongoing attack.

2. yes

This is the most secure setting. * New Host: The client will refuse to connect and will not prompt you to add the key. You must manually add the remote host’s key to your ~/.ssh/known_hosts file before you can connect. * Changed Key: The connection is immediately aborted if the key does not match the saved key.

3. accept-new

This option is ideal for automation and scripting where you want convenience for new servers but security for existing ones. * New Host: The client automatically trusts the new key and adds it to the known_hosts file without asking for user confirmation. * Changed Key: The client strictly refuses the connection if the key for an existing host has changed.

4. no

This is the least secure setting and is generally not recommended for production environments. * New Host: The client automatically adds the host key to known_hosts and connects. * Changed Key: The client allows you to connect even if the host key has changed, though it will print a warning message to the terminal. This leaves the connection highly vulnerable to MITM attacks.