Understand SSH Warning Permanently Added to Known Hosts (2026)

The SSH client is refusing to connect because it detected a change in the remote server’s host key, which is a security measure to prevent man-in-the-middle attacks.

This "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" error is triggered when the SSH server you’re trying to connect to presents a different cryptographic fingerprint (host key) than the one your SSH client has stored locally. Your SSH client, by default, is designed to be paranoid about this. It’s a good thing! It means the system is trying to protect you from a potential attacker impersonating the server you think you’re connecting to.

Here’s what’s really going on:

When you first connect to an SSH server, your client asks for its "host key," which is like its unique digital signature. Your client then stores this key in a file, usually ~/.ssh/known_hosts. The next time you connect, your client checks the server’s presented key against the one it has stored. If they match, great! The connection proceeds. If they don’t match, you get that scary warning.

This mismatch can happen for several legitimate reasons:

The server’s operating system was reinstalled or its disk was replaced. This is the most common benign reason. A fresh OS install or new hardware means the server is generating a brand new host key.
The server’s hostname was re-assigned to a different machine. If an IP address or hostname that used to point to Server A now points to Server B, and Server B has a different key, you’ll see this.
A malicious actor is attempting a man-in-the-middle (MITM) attack. This is the scenario SSH is designed to protect you from. Someone is intercepting your connection and trying to present themselves as the server you intend to reach.
You are connecting to a load balancer or a cluster of servers. If your SSH client connects to different physical machines within a cluster over time, and those machines have different host keys, you’ll see this warning.
Your known_hosts file has become corrupted or contains stale entries. Less common, but possible.

How to Fix It

The core of the fix is to remove the old, incorrect host key entry from your ~/.ssh/known_hosts file so your SSH client will accept the new one.

Step 1: Identify the offending host entry.

The warning message itself usually tells you which host and which line in known_hosts is the problem. It might look something like this:

@@@ @@@ @@@ @@@ @@@ @@@ @@@ @@@ @@@ @@@ @@@ @@@ @@@ @@@ @@@ @@@
@       WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!      @
@@@ @@@ @@@ @@@ @@@ @@@ @@@ @@@ @@@ @@@ @@@ @@@ @@@ @@@ @@@ @@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY
(MAN-IN-THE-MIDDLE ATTACK)!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz0123456789ABCDEF.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/user/.ssh/known_hosts:5
Host key for server.example.com (port 22) does not match.

In this example, the offending entry is on line 5 of /home/user/.ssh/known_hosts for server.example.com.

Step 2: Remove the old entry.

You have a few options, ranging from the most precise to the most general.

Option A: The ssh-keygen -R command (Recommended for Precision)

This is the cleanest and safest method because it specifically targets the host entry you want to remove.

Command:
```
ssh-keygen -R server.example.com
```
If the server uses a non-standard port, you’ll need to specify it:
```
ssh-keygen -R "server.example.com:2222"
```
(Replace server.example.com and 2222 with your actual server address and port.)
Why it works: This command searches your known_hosts file for any lines associated with server.example.com (and the specified port, if any) and removes them. It’s smart enough to handle multiple entries for the same host that might exist across different key types (RSA, ECDSA, ED25519).

Option B: Manually Edit known_hosts (Use with Caution)

If you prefer to see the file yourself, you can manually edit it.

Command to edit:
```
nano ~/.ssh/known_hosts
```
(Or use vim, vi, or your preferred editor.)
What to do: Find the line number indicated in the error message (e.g., line 5 in the example above). Delete that entire line. If the error mentions multiple lines or key types, you might need to delete several. Be very careful not to delete other lines that you know are correct.
Why it works: You’re directly removing the stale or incorrect key entry from the file that your SSH client consults.

Option C: Remove the Entire known_hosts File (Use as a Last Resort)

This is the sledgehammer approach. It will remove all your known hosts, meaning you’ll have to re-authenticate and confirm the host key for every server you connect to from now on.

Command:
```
rm ~/.ssh/known_hosts
```
Why it works: By removing the entire file, you eliminate any potentially incorrect entries. Your SSH client will then prompt you to add the new server’s key as if it were the first time you’re connecting to any server. This is useful if you suspect multiple entries are bad or if you just want a clean slate, but it’s less precise and more inconvenient.

Step 3: Reconnect.

After removing the offending entry, try connecting to the server again:

ssh user@server.example.com

Your SSH client will now fetch the server’s new host key, prompt you to verify it (showing you the new fingerprint), and ask if you want to continue connecting. Type yes and press Enter. The new key will be added to your known_hosts file, and you won’t see the warning anymore for this server.

Important Security Note:

If you suspect a man-in-the-middle attack, do not simply remove the old key and reconnect. Instead, try to verify the server’s identity through an out-of-band channel. Contact your system administrator or the server owner via a different, trusted communication method (e.g., phone call, a different secure chat) and ask them to confirm the server’s correct host key fingerprint. If the fingerprint they provide matches the one your SSH client is showing you after you’ve removed the old entry, then it’s safe to proceed. If the fingerprints still don’t match after you’ve confirmed the server is legitimate, then there is likely a persistent network issue or a genuine MITM attack in progress.

The next error you’ll likely encounter after fixing this is a "Permission denied" error if your SSH keys aren’t set up correctly on the server.

More Deep Dives in Ssh