SSH from Windows system picking up wrong public key from known hosts file

SSH on Windows often connects to the wrong server identity because it caches host keys in %USERPROFILE%\.ssh\known_hosts. This happens when multiple machines share an IP address, such as behind NAT or in dynamic cloud environments. The client trusts the cached key instead of verifying the current server's actual fingerprint, leading to connection failures or security warnings.

Understanding the Known Hosts Mechanism

When you first connect to a remote Linux server via SSH from a Windows machine using tools like OpenSSH Client, PuTTY, or MobaXterm, the system prompts you to accept the server's public key. If you agree, this key is stored in your local known hosts file. On Windows, this file is typically located at C:\Users\\.ssh\known_hosts for native OpenSSH clients. The purpose of this file is security. It ensures that you are connecting to the same server every time and not falling victim to a Man-in-the-Middle (MitM) attack. However, if the server's IP address changes but its hostname remains the same, or if multiple servers are behind a single IP (common in corporate networks or cloud instances), the cached key becomes invalid. The SSH client sees a mismatch between the new server's key and the old one stored in the file, causing it to reject the connection immediately with a "REMOTE HOST IDENTIFICATION HAS CHANGED" error.

Why This Happens Frequently on Windows

Windows users often face this issue more frequently due to several factors:

• Dynamic IPs: Cloud providers often assign ephemeral IPs. If you access a server by hostname, the DNS might resolve to a different IP than before, but the known_hosts file still holds the old key.
• NAT and Load Balancers: Multiple backend servers may share a single public IP. When the load balancer routes your connection to a different backend, the server key changes, triggering the warning.
• Multiple Users/Profiles: If you switch Windows user accounts, each has its own .ssh directory. Confusion can arise if keys are shared or mismanaged across profiles.

For more details on managing SSH connections, you might find Troubleshooting 'Remote side unexpectedly closed network connection' Error in MobaXterm helpful, as MobaXterm also manages its own host key cache separately from the native Windows OpenSSH client.

Solving the Wrong Key Issue

To fix this, you must remove the outdated or incorrect entry from your known hosts file. Follow these steps carefully to ensure you do not delete the wrong entry.

Step 1: Identify the Problematic Entry

First, determine which entry is causing the conflict. You can list all entries in the known hosts file using the following command in PowerShell or Command Prompt:

type %USERPROFILE%\.ssh\known_hosts

Look for the hostname or IP address of the server you are trying to reach. Note the line number or the exact content of the line. Be cautious, as a single line can contain multiple keys separated by commas if you have connected to the same host via different methods.

Step 2: Remove the Incorrect Key

You can remove the specific entry using the ssh-keygen utility, which is safer than manually editing the file. Use the -R flag followed by the hostname or IP:

ssh-keygen -R [hostname_or_ip]

If the server uses a non-standard port, include the port in square brackets:

ssh-keygen -R [hostname]:port

This command will delete the specified entry from the known_hosts file. If you prefer manual editing, open %USERPROFILE%\.ssh\known_hosts in a text editor like Notepad++, find the line corresponding to the problematic server, and delete it entirely. Save the file after removal.

Step 3: Re-establish the Connection

Once the old key is removed, attempt to SSH into the server again:

ssh username@hostname

The client will now detect that there is no cached key for this host. It will display the server's current public key fingerprint and ask if you want to continue connecting. Verify the fingerprint against the server administrator or the official documentation to ensure authenticity. Type yes to accept and store the new key.

Preventing Future Conflicts

To avoid this issue recurring, consider using SSH config files to manage multiple identities for the same IP address. Create or edit %USERPROFILE%\.ssh\config and define specific settings for each host. For example:

Host myserver1
    HostName 192.168.1.100
    User admin
    IdentityFile ~/.ssh/id_rsa_server1

Host myserver2
    HostName 192.168.1.100
    User devops
    IdentityFile ~/.ssh/id_rsa_server2

By using distinct aliases (myserver1, myserver2) for the same IP, SSH treats them as separate entities, maintaining separate key caches. This is particularly useful in environments where multiple services run on the same machine but require different authentication contexts. Additionally, always verify fingerprints when connecting to new or changed hosts. Never blindly accept unknown keys. If you frequently encounter this issue due to dynamic infrastructure, consider implementing automated key management solutions or using certificate-based authentication instead of traditional key pairs. For users experiencing broader connectivity issues alongside key problems, reviewing Troubleshooting kex_exchange_identification Error in Linux SSH Connection can provide insights into other common SSH handshake failures that might compound with host key mismatches.

Frequently Asked Questions

How do I clear all known hosts entries?

You can delete the entire known_hosts file by running del %USERPROFILE%\.ssh\known_hosts in the command prompt. However, this removes trust for all previously connected servers, requiring you to re-verify each one individually upon next login.

Can I disable the known hosts check?

While you can set StrictHostKeyChecking=no in your SSH config, this is strongly discouraged for security reasons. It makes you vulnerable to Man-in-the-Middle attacks by automatically accepting any new server key without verification.

Why does PuTTY show a different key than Windows OpenSSH?

PuTTY stores its host keys in the Windows Registry under HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys, while native Windows OpenSSH uses the known_hosts file. They do not share cache data, so you may need to clear keys in both locations if switching clients.

What if I cannot identify the correct line in known_hosts?

If the file is large, use grep hostname %USERPROFILE%\.ssh\known_hosts to filter only the relevant lines. If you are unsure which key belongs to which server, compare the fingerprints shown in the error message with the expected fingerprints provided by your system administrator.

Does changing the SSH port affect the known hosts file?

No, the standard known_hosts file does not distinguish by port unless you explicitly specify the port in the hostname syntax (e.g., [host]:port). Using the -R flag with just the hostname will remove all entries for that hostname regardless of the port used.