Practical use and limits
Use it for: Treat the warning as a change-control event: obtain the new fingerprint through an independent channel, remove only the exact stale entry, and record why the replacement was trusted.
Limits: A changed host key can indicate a legitimate rebuild or interception. This guide cannot verify your infrastructure; stop when independent verification is unavailable.
What the warning means
SSH stores a fingerprint of the server host key in known_hosts. On a later connection it compares the presented key with the stored key. If the address now presents a different key, SSH stops before user authentication because the connection may be intercepted. The warning does not tell you whether the change is benign; it tells you that the identity you trusted has changed.
Common legitimate causes
A cloud instance may have been rebuilt, a system image may have regenerated host keys, or a public IP may have been reassigned to a different machine. A server administrator may also rotate host keys as part of a security response. Record the change in the maintenance ticket or provider console rather than relying on memory.
Verify before you clean up
Obtain the new fingerprint from the server console, cloud serial console, an administrator on a separate channel, or a documented provisioning output. Compare the algorithm and fingerprint, not a copied public-key filename. If you cannot independently verify the new key, stop. Deleting the warning removes local evidence; it does not make the new server trustworthy.
Remove only the exact stale entry
Once the replacement is verified, remove the entry for the exact hostname or address with ssh-keygen -R. If you connect through an alias, inspect both the alias and the resolved hostname or address. Hashed known_hosts entries are still handled by the tool. Avoid deleting the entire file because it discards trust records for unrelated servers.
Reconnect with a narrow test
Reconnect and accept the verified key, then test the intended account and command. Keep StrictHostKeyChecking enabled for normal use. accept-new can reduce friction for genuinely new hosts while still rejecting changed keys, but it is not a substitute for verifying infrastructure identity. Review known_hosts after migrations and remove only records you can attribute.
Account for ports, aliases, and host certificates
known_hosts can contain separate identities for a hostname, an address, and a non-default port written in bracketed form. ProxyJump, bastions, DNS aliases, and load balancers may also change which host is actually being verified. Inspect the verbose connection output and use ssh-keygen -F to locate matching records before removing anything. If the environment uses SSH host certificates, verify the trusted host CA and certificate principals instead of treating the presented certificate like an ordinary one-off host key.
Create evidence before and after the change
Record the old fingerprint from the warning, the independently obtained new fingerprint, the infrastructure event that explains the change, the person or system that confirmed it, and the time of the first successful connection. Afterward, check recent server authentication and provisioning logs for unexpected access or unplanned key generation. This matters especially when an IP address was recycled: a legitimate new owner explains the mismatch but does not prove that the client intended to reach that new machine.
Bottom line
The correct recovery is verify, remove the exact stale record, and reconnect—not disable host-key checking globally. Host identity and user authentication solve different problems, so a successful password or public-key login does not prove that the server was the intended machine. Treat the warning as part of your deployment change-control process.
Frequently asked questions
Can I just run ssh-keygen -R and reconnect?
Only after you have verified that the server was rebuilt, the IP was reassigned, or the host key was intentionally rotated. Without that check, you may erase an important warning.
Does a changed host key mean my private key is compromised?
Not necessarily. It concerns the server's host identity, not automatically your client private key. Investigate both the infrastructure change and any unusual authentication activity.
Should I disable StrictHostKeyChecking?
No for normal operations. Disabling it hides identity changes and weakens protection against interception. Use an explicit, verified exception only for a controlled bootstrap process.