How to fix the “Warning: Remote host identification has changed” SSH error

The WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! error will stop you dead in your tracks. Despite looking like your server is under attack, this message usually means SSH is working correctly, it’s just spotted something different about your server and wants you to know.

This security check matters, but it can be frustrating when you just need to get back to work. The key is knowing when the error signals a real problem versus routine server maintenance.

This guide covers everything you need to know: what causes the warning, how to tell if it’s dangerous, and how to fix it without compromising your server’s security. You’ll be able to handle this error confidently, whether you’re managing one server or dozens.

Quick Fix (If You Know Your Server is Safe)

Already certain this error came from recent server changes? Remove the old host key with this command:

ssh-keygen -R your-server-hostname

Just swap your-server-hostname for your actual server address. But before you run this, make sure you understand what’s happening. Blindly removing host keys can leave you vulnerable to attacks.

What Does This Error Mean?

To understand the error, you need to know how SSH establishes trust. The first time you connect to a new server, it presents its “public host key”, which is a unique identifier for that server. Your SSH client asks you if you trust this key.

When you type ‘yes’, your computer saves this key and its associated hostname/IP address in a file located at ~/.ssh/known_hosts. This file acts as your personal “phonebook” of trusted servers.

From that point on, every time you connect, the server presents its key again. Your SSH client checks its known_hosts file and says, “Does the key this server is showing me match the key I saved for it last time?”

The “Remote Host Identification Has Changed” error occurs when the answer is NO. The server is presenting a key your computer has never seen before.

Why Did the Host Key Change?

More often than not, this error is caused by routine server administration, not a malicious attack. Here are the most common legitimate reasons:

1. Server OS Reinstallation: If the server’s operating system (e.g., Ubuntu, CentOS) was reinstalled from scratch, the SSH service would have generated a new set of unique host keys. The old ones will have been wiped out with the old OS. This is the most frequent cause.
2. Server Migration or Re-IP: The IP address you are connecting to may have been reassigned. For example, the old server 123.45.67.89 was decommissioned, and a brand new server was spun up and given the same IP address.
3. Cloud/Virtualization Environments: In cloud environments like AWS, GCP, or Azure, virtual server instances can be terminated and replaced. The new instance will have a different host key, even if it has the same IP address or hostname.
4. Load Balancers: If you connect to a hostname behind a load balancer, your connection might be routed to a different server in the pool from the one you connected to last time. You’ll see this error if the servers don’t share the same host key.
5. Deliberate Key Regeneration: A system administrator may have intentionally regenerated the server’s SSH keys for security policy reasons.

The Man-in-the-Middle (MITM) Attack

Although this is usually a benign warning, the error’s primary purpose is to protect you from a Man-in-the-Middle (MITM) attack. Here’s how an MITM attack works in this context:

1. You try to connect to your legitimate server.
2. An attacker, positioned somewhere on the network between you and the server (e.g., on the same public Wi-Fi), intercepts your connection request.
3. The attacker blocks your connection to the real server and instead presents their own fake SSH server to you.
4. Your SSH client sees a new, unexpected host key and throws the “REMOTE HOST IDENTIFICATION HAS CHANGED” error.

If you ignore this warning and proceed, you will send your password or other credentials directly to the attacker’s machine, completely compromising your account. This is why you must verify the cause before you implement any fix.

How to Safely Fix the Error: The “Verify, Then Remove” Protocol

Follow these steps to resolve the issue without compromising your security.

Step 1: VERIFY the New Host Key

This is the most important step. Do not proceed until you have confirmed the new key is legitimate.

• If you are not the server administrator: Contact the person or team that is and ask them if the server’s host key was recently changed. They should be able to confirm if this is the case, and even provide you with the new key’s fingerprint.
• If you are the server administrator: You must get the new key’s fingerprint directly from the server console.
  • Log in to the server using an alternative method (e.g., the web console provided by your cloud provider, like AWS EC2 Connect, GCP Console, or a direct KVM/IPMI connection in a data center).
  • Once logged in, run the following commands to display the fingerprints of the server’s host keys. A server usually has several key types (RSA, ECDSA, ED25519).

# Run these on the remote server you're trying to connect TO (not on your personal laptop)
ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Compare this fingerprint with the one your local SSH client shows you in the error message. If they match, you have successfully verified the new key is authentic.

Step 2: REMOVE the Old Host Key from known_hosts

Once you’ve verified the new key’s authenticity, you can safely remove the old, conflicting key from your local ~/.ssh/known_hosts file. The ssh-keygen command has a specific function for removing hosts.

On your local machine (the one you are connecting from), run the following command, replacing your-server-hostname with the actual hostname or IP address from the error message:

ssh-keygen -R your-server-hostname

Open the file with your favorite text editor:

nano ~/.ssh/known_hosts

Go to the line number mentioned in the error and delete that entire line. The line will start with the hostname or IP address. Save the file and exit the editor.

Step 3: Reconnect and Accept the New Key

Now that the old key is gone, try your SSH connection again. You will be prompted to accept the new key as if you were connecting for the first time. Since you have already verified its fingerprint, you can confidently type ‘yes’.

Conclusion

In this post, we have seen that the “Warning: Remote host identification has changed” error is an important security mechanism that is doing its job. By following the steps in this article, you can confidently handle this common issue while ensuring your connections remain secure.

Managing servers and deploying new web applications can be challenging, especially if you are unfamiliar with Linux and the command line.

That’s why we built RunCloud.

With RunCloud, you can deploy and manage your web applications, databases, and firewalls directly from an intuitive dashboard, completely sidestepping common issues like the “Remote Host Identification Has Changed” error.

Sign up for RunCloud today and experience hassle-free web server management.

FAQs About the SSH Host Key Warning