•
5 min read

How to Resolve SSH: REMOTE HOST IDENTIFICATION HAS CHANGED!

Fix the SSH remote host identification warning by removing stale host keys and verifying the new fingerprint safely.

SSH Linux Security Troubleshooting
Share:

Introduction

When you see REMOTE HOST IDENTIFICATION HAS CHANGED!, SSH is telling you the server’s public key no longer matches the fingerprint stored in your ~/.ssh/known_hosts file. This happens after a server reinstall, IP address reassignment, or infrastructure migration. It can also signal a man-in-the-middle attack. The fix is straightforward, but you should verify the new key before accepting it.

The Full Error Message

Here is what the warning looks like in practice:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
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 ED25519 key sent by the remote host is
SHA256:xPPKz1r8h+EXAMPLE+NOT+REAL+KEY+abcdef1234.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:47
Host key for 192.168.1.50 has changed and you have requested strict checking.
Host key verification failed.

Two pieces of information matter here:

  1. The file and line number containing the old key (known_hosts:47 in this example).
  2. The fingerprint of the new key the server is presenting.

Why This Happens

SSH stores a fingerprint of every server you connect to inside ~/.ssh/known_hosts. On the next connection, SSH compares the server’s current key against that stored fingerprint. A mismatch triggers the warning.

Legitimate causes:

  • Server was rebuilt or reimaged.
  • Cloud instance was destroyed and recreated with the same IP or hostname.
  • SSH host keys were regenerated manually (ssh-keygen -A).
  • A load balancer or floating IP now points to a different machine.
  • The server’s SSH daemon was upgraded and switched key types (for example, from RSA to ED25519).

Illegitimate cause: someone is intercepting traffic between you and the server.

Step 1: Verify the New Key

Before removing anything, confirm the new fingerprint is legitimate. Skip this step only if you personally just rebuilt the server and know the key changed.

If you have console access (cloud provider web console, IPMI, or physical terminal), log into the server directly and run:

Terminal window
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Output looks like:

256 SHA256:xPPKz1r8h+EXAMPLE+NOT+REAL+KEY+abcdef1234 root@server (ED25519)

Compare this fingerprint against the one SSH printed in the error message. If they match, the key change is legitimate. If you cannot get console access, contact whoever manages the server and ask them to read back the fingerprint.

For RSA or ECDSA keys, substitute the appropriate file:

Terminal window
ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub

Step 2: Remove the Old Key

Once you have confirmed the new fingerprint, remove the stale entry. The cleanest method uses ssh-keygen -R:

Terminal window
ssh-keygen -R 192.168.1.50

If you connected by hostname:

Terminal window
ssh-keygen -R myserver.example.com

If the server uses a non-standard port:

Terminal window
ssh-keygen -R "[myserver.example.com]:2222"

This command removes all keys associated with that host from ~/.ssh/known_hosts and creates a backup file (known_hosts.old).

You can also remove the specific line manually. The error message told us line 47:

Terminal window
sed -i '47d' ~/.ssh/known_hosts

On macOS (BSD sed), the syntax differs slightly:

Terminal window
sed -i '' '47d' ~/.ssh/known_hosts

Step 3: Reconnect

Terminal window
ssh user@192.168.1.50

SSH will prompt you to accept the new key:

The authenticity of host '192.168.1.50 (192.168.1.50)' can't be established.
ED25519 key fingerprint is SHA256:xPPKz1r8h+EXAMPLE+NOT+REAL+KEY+abcdef1234.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Type yes. The new fingerprint is now stored in known_hosts.

Handling Multiple Hosts at Once

If you manage many servers and frequently rebuild them (lab environments, CI runners, ephemeral cloud instances), clearing keys one by one gets tedious. A few options:

Clear all keys for a subnet using a loop:

Terminal window
for i in $(seq 1 254); do
  ssh-keygen -R "192.168.1.$i" 2>/dev/null
done

Disable strict host key checking per host in ~/.ssh/config:

Host lab-*
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
    LogLevel ERROR

This sends known_hosts writes to /dev/null and suppresses the warning entirely for hosts matching lab-*. Use this only for disposable, non-production machines. Setting this globally is a serious security risk because it disables the exact protection SSH provides against interception.

Hashed known_hosts Entries

Some distributions hash hostnames in known_hosts by default (controlled by HashKnownHosts yes in /etc/ssh/ssh_config). When hashing is enabled, you cannot grep the file for a hostname because entries look like this:

|1|base64salt=|base64hash= ssh-ed25519 AAAAC3Nza...

ssh-keygen -R hostname still works correctly with hashed entries. It is the reliable removal method regardless of hashing.

To check whether a specific host exists in a hashed known_hosts file:

Terminal window
ssh-keygen -F 192.168.1.50

When the Warning Appears for GitHub or GitLab

GitHub rotated its RSA SSH host key on March 24, 2023. If you still have the old key cached, you will see this error when pushing or pulling over SSH.

Remove the old key:

Terminal window
ssh-keygen -R github.com

Then verify the new fingerprint against GitHub’s published fingerprints at https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints before reconnecting.

The same process applies to GitLab, Bitbucket, or any hosted Git service that rotates keys.

Troubleshooting

Error: known_hosts:47: invalid line

The file has a corrupted or truncated line. Open it in an editor, go to line 47, and delete it. Or use sed -i '47d' ~/.ssh/known_hosts.

Error: Bad owner or permissions on ~/.ssh/known_hosts

SSH refuses to read the file if permissions are too open:

Terminal window
chmod 644 ~/.ssh/known_hosts
chmod 700 ~/.ssh

Key removed but warning persists:

Check whether you have a system-wide known_hosts file at /etc/ssh/ssh_known_hosts. The stale key may live there instead of in your home directory:

Terminal window
sudo ssh-keygen -R 192.168.1.50 -f /etc/ssh/ssh_known_hosts

Also check if your SSH config includes additional UserKnownHostsFile directives:

Terminal window
ssh -vvv user@192.168.1.50 2>&1 | grep "known hosts"

The verbose output shows every known_hosts file SSH reads.

Multiple entries for the same host:

A host can have entries under its IP, its hostname, and its FQDN. Remove all of them:

Terminal window
ssh-keygen -R 192.168.1.50
ssh-keygen -R myserver
ssh-keygen -R myserver.example.com

Security Considerations

The host key warning exists to protect you. Blindly removing keys and reconnecting without verifying the new fingerprint defeats the purpose of SSH’s trust model. If you did not expect the key to change, treat it as suspicious until you can confirm the cause through an out-of-band channel (cloud console, phone call to the admin, provider status page).

Setting StrictHostKeyChecking no globally in your SSH config is the equivalent of clicking “Accept” on every browser certificate warning. Restrict that setting to specific host patterns where you understand and accept the risk.

Found this article helpful? Share it

Back to Articles