Verify a Changed SSH Host Key Before Replacing Its Saved Identity
A changed SSH host-key warning can follow a legitimate server rebuild, but it can also mean you reached a different machine. Treat it as an identity question before treating it as an inconvenient login failure. Keep the exact hostname, port, key type and displayed fingerprint.
Verify through an established route
Ask the responsible administrator whether the server was rebuilt or its host keys deliberately rotated. Obtain the current fingerprint through a previously trusted management console or established contact channel. A fingerprint copied from the same unverified connection is not an independent comparison.
Compare the complete fingerprint for the same key type and destination. Check whether an address was reassigned or the saved connection points at an old host. Do not substitute a similar hostname because its login screen looks familiar.
OpenSSH stores known host identities and warns when they change. The administrator can inspect a server public-key fingerprint with ssh-keygen -l -f followed by that public-key file's path. No private server key needs to be sent to the client.
Correct only the verified entry
On the client, ssh-keygen -F can find the saved hostname, including hashed entries; a nonstandard port uses the documented [hostname]:port form. Preserve a copy of the existing known_hosts file before changing it.
Only after the replacement identity is independently confirmed should you remove that destination's old entries with ssh-keygen -R using the same host-and-port scope. Do not delete the whole file or disable host-key checking to clear a single warning.
Reconnect to the intended destination and compare the presented fingerprint again before accepting it. Record who confirmed the change and which server maintenance explained it. If the fingerprint still differs, stop the connection and return that discrepancy to the administrator.
After authentication, confirm the expected account and server context before performing work. A repaired trust record is not evidence that a previous transfer or remote command completed; inspect those outcomes separately before repeating them.
Sources: Ubuntu documentation, Ubuntu documentation.