SSH Credentials Added Twice: Unable to Remote Connect via SSH on Ubuntu

SSH credentials appearing twice in ~/.ssh/known_hosts causes connection failures because the SSH client detects a host key mismatch when multiple entries exist for the same IP address. This issue typically arises from re-imaging servers, changing network configurations, or connecting to different machines with identical IPs. The solution involves cleaning the duplicate entries using the ssh-keygen -R command to restore secure connectivity.

Understanding the Known Hosts Mechanism

When you connect to an SSH server for the first time, your local machine prompts you to verify the server's fingerprint. Upon acceptance, this public key is stored in the ~/.ssh/known_hosts file. This mechanism prevents Man-in-the-Middle (MitM) attacks by ensuring that the server you are connecting to has not changed its identity unexpectedly. The SSH client reads this file sequentially. If it finds more than one entry for the same hostname or IP address, it cannot determine which key is the correct one. Consequently, it aborts the connection and displays an error message indicating that the host key for the site has changed or that there are conflicting entries. This behavior is a security feature, not a bug, designed to protect users from connecting to potentially compromised hosts.

Common Causes of Duplicate Entries

Several scenarios can lead to duplicate SSH credentials being added to your local configuration. Identifying the root cause helps prevent recurrence after you fix the immediate issue.

• Server Re-imaging: If you reinstall an operating system on a physical server without changing its IP address, the new installation generates a different SSH host key. Your local machine still holds the old key, resulting in two conflicting entries.
• NAT or DHCP Conflicts: In home lab environments or virtualized setups, dynamic IP assignment may give the same IP address to different virtual machines. Connecting to the IP twice effectively adds keys for two different hosts under the same identifier.
• Manual Editing Errors: Accidentally copying and pasting lines into the known_hosts file or merging files from different systems can introduce duplicates manually.

For more context on related SSH connectivity issues, such as hangs in VirtualBox environments, you might find Troubleshooting SSH Hangs on Kubuntu 24.04 and Ubuntu 24.01 in VirtualBox useful. Additionally, understanding permission issues can help if your cleanup commands fail due to file access rights, as discussed in SSH Permission Denied on Port 22: Home Lab Server Issue.

Identifying the Problem in Terminal Output

When the issue occurs, the terminal output will explicitly mention the conflict. You might see an error similar to:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
It is possible that someone is doing something nasty!
...
Offending ECDSA key in /home/user/.ssh/known_hosts:5
Offending ECDSA key in /home/user/.ssh/known_hosts:12
Password authentication is disabled or not configured.

Note the line numbers provided (e.g., :5 and :12). These indicate exactly where the duplicate keys reside in your file.

Solving the Duplicate Key Issue

The most efficient way to resolve this is to remove the offending entries automatically rather than editing the file manually. Manual editing risks introducing syntax errors or leaving behind partial lines that could still cause issues. Use the ssh-keygen utility with the -R flag. This flag tells SSH to remove all keys associated with the specified hostname or IP address.

Step-by-Step Removal Process

1. Identify the Hostname or IP: Determine the exact string used in your SSH command. For example, if you ran ssh [email protected], the target is 192.168.1.50.
2. Run the Removal Command: Execute the following command in your terminal:

   ssh-keygen -R 192.168.1.50

   If you use a hostname like myserver.local, replace the IP with that hostname.
3. Verify the File: You can check the status of the file by viewing its contents. Use cat ~/.ssh/known_hosts to ensure the duplicate lines are gone. The command output usually confirms how many keys were removed.
4. Reconnect: Attempt to SSH into the server again. You will be prompted to accept the new host key. Type yes to add the current, correct key to your list.

If you have multiple duplicates or are unsure which ones are valid, you can remove all entries for a specific host by running the command again. SSH only stores one active key per host; any subsequent connections will update this single entry.

Handling Persistent Issues

In rare cases, the ssh-keygen -R command might not remove the entry if the file has incorrect permissions. Ensure that the known_hosts file is owned by your user and has read/write permissions for the owner only. You can reset permissions using:

chmod 600 ~/.ssh/known_hosts

This ensures that only you can read or modify the file, which is a standard security practice for SSH configurations. If you continue to experience connection problems, consider checking for broader network or service issues, such as those described in Troubleshooting SSH WSL Machine: Can't Connect to Localhost, particularly if you are working within a Windows Subsystem for Linux environment.

Preventing Future Conflicts

To minimize the risk of encountering duplicate keys again, adopt consistent naming conventions. Instead of relying solely on IP addresses, use static hostnames in your ~/.ssh/config file. This allows you to map specific IPs to unique aliases, making it easier to manage multiple servers that might share temporary IP ranges. Additionally, regularly audit your known_hosts file if you frequently rebuild infrastructure. Automated scripts can compare expected fingerprints against stored keys to alert you before a connection attempt fails.

Frequently Asked Questions

What does "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED" mean?

This warning indicates that the SSH server at the specified IP address has presented a different cryptographic key than what is stored in your local known_hosts file. It is a security measure to prevent Man-in-the-Middle attacks, suggesting either a legitimate server change or a potential security breach.

Can I edit the known_hosts file manually instead of using ssh-keygen?

While you can manually edit the file using a text editor like nano or vim, it is error-prone. Deleting specific lines requires knowing the exact line number, and accidental deletion of other entries can break connections to other servers. Using ssh-keygen -R is safer and more precise.

Why do I still get the error after removing the key?

If the error persists, you may have connected to a different server that now occupies the same IP address, or you have another stale entry for a different hostname resolving to that IP. Verify the server's actual fingerprint with its administrator and ensure you are removing the correct identifier from your local configuration.

Is it safe to ignore the warning and type yes?

No, never ignore this warning without verifying the server's identity through a separate channel. Ignoring it exposes you to MitM attacks where an attacker intercepts your connection. Always confirm the new fingerprint matches the official documentation or a trusted source before accepting it.

How do I check my current SSH version and config settings?

You can check your SSH client version by running ssh -V. To view detailed configuration options during a connection attempt, use ssh -v user@host or ssh -vvv for verbose debugging. This output shows exactly which keys are being loaded and where conflicts arise.