How to Resolve an SSH Host Key Changed Warning Safely
“REMOTE HOST IDENTIFICATION HAS CHANGED” means the identity key presented by the server differs from the one previously saved. The change may be legitimate, but it should never be accepted without verification.
What does the host key changed warning mean?
An SSH client saves the host key of a server it has seen before. On a later connection to the same host and port, the presented key is compared with that record. A mismatch triggers a warning or stops the connection.
This check helps prevent an unnoticed connection to a system impersonating the expected server. Disabling the warning simply to get connected removes an important identity check.
Why can a server host key change?
Reinstalling the operating system or SSH service may generate new host-key files.
An administrator may replace an old algorithm or rotate keys under a security policy.
A cloud or hosting address may now belong to a different virtual server.
One name may reach backend systems that do not share consistent host keys.
A DNS, routing or interception problem may direct the client to an unexpected machine.
How to verify the new fingerprint
- 1Stop the connection
Do not automatically accept a key that differs from the saved value.
- 2Check host and port
Rule out a typing mistake, outdated profile or incorrect DNS name.
- 3Use an independent channel
Obtain the fingerprint from the hosting console, local server console or administrator. Information from the suspect connection is not independent.
- 4Compare key type and fingerprint
Confirm both the ED25519, ECDSA or RSA type and the displayed fingerprint.
- 5Replace the record only after confirmation
Remove the old known-host entry and save the new key once the change is verified.
How to remove the old known_hosts entry
On systems using OpenSSH, ssh-keygen can remove the record for one destination. A connection on a custom port may be stored using a combined host-and-port form.
Deleting the entire known_hosts file also discards identity history for every other server. Remove only the entry connected to the verified change.
ssh-keygen -R server.example.comssh-keygen -R "[server.example.com]:2222"What should you do in a mobile client?
Before clearing a saved host-key decision, verify why it changed and check that the host and port in the profile still point to the expected system.
After confirmation, remove the old trust record for that server, reconnect and compare the newly displayed fingerprint. Deleting the entire connection profile is normally unnecessary.
Approaches to avoid
Turning off strict host-key verification can also accept future impostor servers.
A value supplied by the suspicious channel is not a trusted second source.
Do not lose the identity history of unrelated servers for one key change.
Connections made under different names can have separate known-host entries.
If the administrator cannot confirm the new key, disconnect before sending a password or using a private key.
Put the guide into practice.
Review the related Varkuna product or open its detailed user guide.