SSH Host Key Changes: Risks with UpdateHostKeys=no

TL;DR

If you’ve set UpdateHostKeys no in your SSH config for a server, changing the server’s host key *without* updating your client’s known_hosts file will cause connection problems and potential man-in-the-middle (MITM) attacks. It’s generally best to keep UpdateHostKeys yes unless you have a very specific reason not to.

Understanding the Problem

SSH uses host keys to verify that you’re connecting to the correct server. Your SSH client stores these keys in a file called known_hosts (usually located in your user’s .ssh/ directory). When you connect, SSH checks if the server’s key matches what’s in known_hosts.

The UpdateHostKeys option controls whether SSH automatically updates these keys when connecting to a server. Setting it to no means SSH won’t check for changes and *won’t* warn you if the key has been altered.

Negative Consequences of Changing Host Keys with UpdateHostKeys=no

1. Connection Refusals: If the server’s host key changes, SSH will detect a mismatch against your known_hosts file. Because UpdateHostKeys no is set, it won’t attempt to update the file. This results in an error message and connection failure. You’ll likely see something like “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!”.
2. Man-in-the-Middle (MITM) Attacks: This is the biggest risk. If someone intercepts your SSH connection, they can present their own host key. With UpdateHostKeys no, your client won’t detect this change and will happily connect to the attacker’s server, potentially exposing your credentials and data.
3. Broken Automation: Scripts or automated processes relying on SSH connections will fail if the host key changes and isn’t updated in known_hosts.

How to Fix It

The best solution depends on why you originally set UpdateHostKeys no. Here are a few approaches:

1. Recommended: Re-enable Host Key Updates

1. Edit your SSH config file (usually ~/.ssh/config).
2. Change the line for the affected host to:

   Host hostname
   UpdateHostKeys yes
   

3. Connect to the server again. SSH will prompt you to verify the new key and add it to known_hosts.

   You’ll see a message like:

   The authenticity of host 'hostname (IP address)' can't be established.
   ECDSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   Are you sure you want to continue connecting (yes/no/[fingerprint])?

4. Type yes if the displayed fingerprint matches what you expect from the server administrator.

2. Manually Update known_hosts

If you *must* keep UpdateHostKeys no, you need to manually update your known_hosts file.

1. Get the new host key from the server: Use a secure method (e.g., directly from the server console or a trusted source) to obtain the current public SSH host key.

   ssh-keyscan hostname

2. Edit your known_hosts file: Open ~/.ssh/known_hosts with a text editor.
3. Remove the old entry for the host: Find the line corresponding to the server’s hostname and delete it. Be careful not to accidentally remove other entries!
4. Add the new key: Paste the output from ssh-keyscan into your known_hosts file on a new line.
5. Verify the connection: Connect to the server again to ensure it works.

   If you’ve done this correctly, SSH should no longer display the warning message.

3. Temporary Workaround (Use with Caution)

As a *temporary* measure, you can bypass host key checking entirely (not recommended for production). This is extremely risky and should only be used in controlled environments.

1. Add the following to your SSH config file:

   Host hostname
   StrictHostKeyChecking no
   UserKnownHostsFile=/dev/null

2. Connect to the server.
3. Immediately revert these changes after verifying the connection and updating known_hosts using one of the methods above.

   Leaving StrictHostKeyChecking no enabled makes you vulnerable to MITM attacks.

Important Considerations

• Fingerprint Verification: Always verify the host key fingerprint with a trusted source (e.g., server administrator, official documentation) before adding it to your known_hosts file.
• Security Best Practices: Regularly review and update your SSH configuration for optimal security.