Understanding and Resolving SSH Host Key Verification Failures
Secure Shell (SSH) is a fundamental tool for secure remote access to servers and networked devices. A common issue encountered by SSH users is the "REMOTE HOST IDENTIFICATION HAS CHANGED" warning. This message, while alarming, is a security feature designed to protect against potential "man-in-the-middle" attacks. This tutorial explains why this warning appears and how to resolve it safely.
Why Does This Warning Appear?
SSH identifies servers by verifying their host key. This key is a cryptographic fingerprint unique to each server. When you connect to a server for the first time, SSH stores the server’s host key in a file called known_hosts
. Subsequent connections verify that the server’s current host key matches the stored key.
The "REMOTE HOST IDENTIFICATION HAS CHANGED" warning appears when SSH detects a mismatch between the stored host key in your known_hosts
file and the key presented by the server. This can happen for several reasons:
- Server Reinstallation: If you’ve reinstalled the server’s operating system, a new host key will be generated.
- Server Migration: Moving a service to a new server will result in a different host key.
- Server Compromise: Although less common, a compromised server might have its host key maliciously altered.
- Network Interception (Man-in-the-Middle Attack): An attacker could intercept your connection and present a fake host key, attempting to impersonate the server. This is what SSH is protecting against.
Resolving the Warning
The appropriate solution depends on why the key has changed. Here are several methods, starting with the safest and most common:
1. Removing the Old Entry from known_hosts
This is the most common solution, especially after a server reinstallation or migration. You need to remove the outdated entry for the server from your known_hosts
file.
The ssh-keygen
command provides a convenient way to do this:
ssh-keygen -R <hostname_or_ip_address>
Replace <hostname_or_ip_address>
with the hostname or IP address of the server you’re connecting to. For example:
ssh-keygen -R 192.168.1.100
This command removes all entries related to the specified host from your known_hosts
file. The next time you connect, SSH will prompt you to verify the new host key, ensuring you are connecting to the correct server.
Important Note: If your known_hosts
file is managed by a central authentication system (like FreeIPA), the location of the file may differ from the default ~/.ssh/known_hosts
. You may need to consult your system administrator or the documentation for your authentication system to locate and modify the correct file. In the example case of FreeIPA, the known_hosts
file is typically located at /var/lib/sss/pubconf/known_hosts
.
2. Manually Editing known_hosts
(Advanced)
If you need more granular control, you can manually edit your known_hosts
file.
- Open the file in a text editor.
- Locate the line corresponding to the server you’re having trouble with. The line will start with the server’s hostname or IP address.
- Delete the entire line.
- Save the file.
Caution: Editing known_hosts
manually requires care. Ensure you are deleting the correct line, as removing the wrong entry could compromise the security of your connections.
3. Removing All Known Hosts (Drastic, Use with Caution)
As a last resort, you can remove all entries from your known_hosts
file. This is a drastic measure, as you’ll need to re-verify the host keys for all servers you connect to.
rm ~/.ssh/known_hosts
Or, if the file is in a non-default location:
rm /var/lib/sss/pubconf/known_hosts
Important Considerations:
- Verification: After removing the old entry or clearing the
known_hosts
file, always verify the server’s new host key when prompted. Compare the fingerprint shown by SSH with the fingerprint provided by the server administrator through a trusted channel (e.g., phone, secure website). - Security: Never blindly accept a new host key without verification. Doing so could leave you vulnerable to a man-in-the-middle attack.
- Centralized Authentication: If your system uses a centralized authentication system like FreeIPA, consult its documentation for the correct way to manage
known_hosts
files.