How to Fix the “Warning: Remote Host Identification Has Changed” Error

The “Warning: Remote Host Identification Has Changed” error is especially annoying when it pops up while trying to SSH into a server. This warning indicates a potential security issue which is designed to guard you against possible man-in-the-middle (MITM) attacks. However, it can also happen because of a genuine change in the configuration of your server.

In this tutorial, we will examine the most prevalent reasons and the solutions for the “Warning: Remote Host Identification Has Changed!” issue.

Common Causes of the Error

During the first time doing an SSH to a server, a new entry gets created in the form of a file known as known_hosts. It serves as a verification, enabling the user to SSH onto the server. However, in case the server loses its host key, then the matching SSH folder might result in an alarming issue: 

SSH uses certain cryptography keys to enable the identification of various remote servers. A new server’s key gets stored in a folder titled /~/.ssh/known_hosts. On further connections, the rest of the keys are checked against the folder. As this gets done over multiple times, in case there is any change with it, a warning is displayed.

Here are the common reasons:

1. Server Reinstallation or OS Upgrade: The SSH host key gets regenerated. It occurs within a scenario where a server is reinstalled, or reconfigured along with changing the SSH key.
2. IP Address Reassignment: You’re connecting to a different server with the same IP or hostname.
3. Legitimate Key Rotation: Some administrators periodically change SSH keys.
4. MITM Attack (Rare but Serious): An actual man-in-the-middle attack, or an alternative form known as DNS spoofing, could have occurred, but it’s infrequent and severe.

How to Fix the Error

First, if the change of the key is expected, ensure that your server administrator has been consulted prior. If it is legitimate, do the following:

Method 1: Remove the Old Host Key (Recommended)

The error can be fixed by deleting the outdated SSH key, which is stored in the known_hosts directory on your machine. Whenever you connect to a server for the first time, the SSH client identifies the server with the fingerprint stored in the file. In case the fingerprint has been modified for any reason, like changing the IP address, you will receive the warning.

The easiest solution is to remove the key causing issues from known_hosts. Find the suspicious record by executing the following command:

ssh-keygen -F

Let’s replace hostname_or_ip with actual IP:

ssh-keygen -F 18

It indicates that lines 8 and 9 of the known_hosts file contain the incorrect key for this host.

Proceed to removing the conflicting key with the following syntax:

ssh-keygen -R <hostname_or_ip>

For instance, the following command will eliminate the exact entry:

ssh-keygen -R 192.168.100.4

It modifies the known_hosts file for you, so you don’t need to manually open or modify anything.

Reconnect to the server. Once again, the latest key will be stored:

ssh user@hostname_or_ip

For example, the following command connects to the computer at IP address 192.168.100.4, and logs in as user anees:

ssh [email protected]

Type yes to storing securely the historical marker and reconciling the saved fingerprints with your known_hosts.

This gives you the added advantage of removing, cleaning up, or restoring recognized markers without the need to disable protective approaches that permit trusting network faces and risk attack. It allows you to modify network trust and verify key values securely and thereby restore the protective barriers that could be undermined.

Method 2: Manually Edit the known_hosts File

If you prefer more control or want to remove only a specific entry, manually editing the known_hosts file is a straightforward way to resolve the “WARNING REMOTE HOST IDENTIFICATION HAS CHANGED” error.

The known_hosts file contains all of the fingerprints (or host keys) of remote servers that you have ever connected to. This record of connection helps SSH confirm that it is connecting with the same trusted server every time a connection is attempted. It also prevents unauthorized access by throwing a warning when a key gets changed (reinstalled, migrated, or is subject to spoofing by another server using her IP).

In case ssh-keygen -R does not resolve the issue, then you can solve this problem by manually editing the file.

To locate the known_hosts file:

nano ~/.ssh/known_hosts

You can open it with Vim, code, or any other preferred editor. As stated previously, this file contains one line per host you have ever connected to.

Proceed to your preferred text editor to find and delete the line containing the problematic line (host/IP). Save the changes and quit the editor. Go ahead to reconnect through SSH:

ssh [email protected]

Keep in mind that the confirmation for adding the new fingerprint to the known_hosts file will need to be accepted as the system prompts for such an action.

Method 3: Disable Strict Host Key Checking (Temporary Fix – Not Recommended)

Disabling strict host key checking avoids the warning completely, which can be quite advantageous in auto-operated setups such as scripts and CI/CD pipelines, as well as provisioning tools like Ansible or Terraform. This particular method instructs SSH to connect to the specified host while ignoring the identity verification process completely, thus skipping the “host key mismatch” warning.

If you are operating within a trusted environment, such as a testing environment, the check can be bypassed temporarily like so:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@hostname_or_ip

In this example, -o Scrod -o UserKnownHostsFile=/dev/null are sufficient to the requirements.

-o UserKnownHostsFile=/dev/null: This option prevents the saving of host keys to the known_hosts file. Unlike /dev/null, which changes its actual location, thus making verification useless:

None of these changes pose security risks, however, the opposite can be said if applied in a sensitive production server. As noted previously, an important security feature will be completely restrained, which checks if the unit you are connecting to is actually correct. Losing detection measures in case someone attempts to impersonate the server would open uncontrollable gaps for MITM attacks to occur.

Method 4: Update the Key Manually (For Controlled Environments)

Having full access to a remote server (internal servers, dev machines, or even VMs that you manage), resolving this warning by manually changing the SSH host key will be less of a hassle. The procedure for this method is to ensure that you confirm the server’s trust first before replacing the old key in your ~./ssh/known_hosts folder with the new key.

If you have the new host key, you can manually add it:

ssh-keyscan -H hostname_or_ip >> ~/.ssh/known_hosts

As an example, use the command below:

ssh-keyscan -H 192.168.100.4 >> ~/.ssh/known_hosts

Best Practices to Avoid This Issue

As the warning says “SSH REMOTE HOST IDENTIFICATION HAS CHANGED”, it is for your protection. Usually within one or two minutes, the problem can be fixed. Always make sure that it is not a more malicious problem.

• Use DNS or SSHFP Records: They enhance automation in key verification.
• Document Key Changes: Inform users ahead of time when revoking SSH keys.
• Automate Key Deployment: Ansible uses secure methods to distribute the keys.
• StrictHostKeyChecking must never be turned off: This setting should not be changed. So, in /etc/ssh/ssh_config, don’t disable checks forever.

Conclusion

The “Remote Host Identification Has Changed” error arises when the remote server you want to SSH to has a host key that differs from the one at your local machine. Take the time to inspect the changes made to the key. The best command is ssh-keygen -R to remove the key and add it again.

The ssh-keygen -R hostname command is a way to eliminate outdated keys. Always check the key before permitting and avoid skipping the ssh security checks. It could breach them at a point where they fully trust the network.

FAQ