How to fix the REMOTE HOST IDENTIFICATION HAS CHANGED error in SSH

The notice REMOTE HOST IDENTIFICATION HAS CHANGED This appears when the SSH client detects that the server's identity key does not match the one it had registered for that destination. This can happen after rebuilding a server or reassigning an IP address, but it can also indicate that you are connecting to a different machine.

The solution involves verifying the new identity and updating the corresponding entry in known_hostsDo not delete the entire file or disable security checks to make the message disappear.

Verify the new server fingerprint before changing known_hosts

Read the entire warning and check the destination, key type, new fingerprint, and the file where the conflicting entry appears. Also, confirm that you are using the expected name, IP address, and port.

To verify the fingerprint, use a separate path from the connection that is showing the warning: a provider console that you already have authorized access to, a physical console, or an administrator identified by a known channel.

On a Linux server with a host key Ed25519 in its usual location, you can check its fingerprint from that console:

ssh-keygen -l -E sha256 -f /etc/ssh/ssh_host_ed25519_key.pub

Compare the complete result with the one displayed by the client. If the warning corresponds to an RSA or ECDSA key, look up the public key of that same type. Locations may vary depending on the server configuration.

If you cannot verify the change, do not accept the new identity. Request confirmation from the administrator or provider before proceeding.

What does REMOTE HOST IDENTIFICATION HAS CHANGED mean?

In typical OpenSSH usage, the client stores the public keys of known servers and verifies them on subsequent connections. fingerprint It is a summary of a key, used to facilitate its comparison.

These keys identify the server and are different from the personal keys you use to log in. Therefore, changing your password or generating a new user key will not fix this warning.

The warning alone doesn't prove an attack is underway, but it prevents you from accepting the previous identity as valid. Ignoring it could lead you to trust a machine that is impersonating the intended destination.

What legitimate changes can trigger the notice

Check if any of these situations have occurred:

• Reconstruction or reinstallation: The server may have generated new keys.
• Machine replacement: Another server may have received the same IP address.
• Key rotation: The administrator may have replaced the host keys.
• Change of destination: A DNS name, alias, or local IP address may be pointing to another computer.

On cloud platforms, rebuilding an instance or reusing an IP address can cause this conflict. Even so, The administrative change must be accompanied by verification of the new fingerprint.

A system update doesn't necessarily mean the passwords will change. If no one recognizes the change, investigate the destination before modifying the saved information.

Remove only the old entry from the verified destination

Once the identity is verified, execute the command in the client device that displays the noticeusing the corresponding destination:

ssh-keygen -R servidor.ejemplo.com

If you connect via an IP address, use that IP address:

ssh-keygen -R 203.0.113.10

For a port other than the usual one, include the destination in brackets and the port:

ssh-keygen -R "[servidor.ejemplo.com]:2222"

The command removes the keys registered for that destination in the corresponding known hosts file. It does not verify the new key or change the server's keys.

Do not delete entries from other devices. If you switch between name and IP address, check which one is involved in the warning before modifying both.

Where is known_hosts located in Windows, macOS, and Linux?

In a typical OpenSSH client configuration, you will find the user file in these locations:

• Linux and macOS: ~/.ssh/known_hosts.
• OpenSSH on Windows: %USERPROFILE%\.ssh\known_hosts.

The path shown in the warning is the reference you should check. There may be a custom configuration or a global file managed by your organization.

To look up an entry, even if the name is stored using a hash, use:

ssh-keygen -F servidor.ejemplo.com

If the prompt points to a different file, you can specify it with -f. For example:

ssh-keygen -R servidor.ejemplo.com -f "/ruta/indicada/known_hosts"

Applications used by other clients, such as PuTTY, can maintain trust with servers in a different way. This procedure is handled by OpenSSH.

Reconnect and compare the footprint before accepting

Repeat the connection with the correct name and port:

ssh [email protected]

Or, if you're using a custom port:

ssh -p 2222 [email protected]

In the usual configuration, SSH will request confirmation for the new key. Accept only if their fingerprint matches the one you have verified.. If it doesn't match, stop the connection.

If the conflict reappears, check if you modified the correct file, if you are connecting with a different local user, or if the configuration uses a host key alias. In managed environments, request an update to the trust registry from your administrator.

What you shouldn't do to remove the warning

Don't delete everything known_hostsYou would lose the identity references from other servers. Also, do not use StrictHostKeyChecking=no as a general arrangement, because it reduces the check that has detected the change.

ssh-keyscan It allows you to obtain the keys presented by a destination, but it doesn't prove that they belong to the legitimate server. Adding its output directly to known hosts without verifying it maintains the same trust problem.

For planned rotation, the manager can study mechanisms such as UpdateHostKeysThis allows you to learn additional keys from an already authenticated connection. However, this does not replace the verification of an unexpected change.