SSH Host Key Changed: Verify Before Reconnecting

An SSH host-key warning means the server identity presented now differs from the identity your client remembers. It may follow a legitimate rebuild, but it can also indicate that you reached the wrong machine. Verify the new fingerprint through a trusted channel before replacing the saved key.

Do not make the warning disappear by disabling host-key checking globally. The useful question is why the identity changed. A quick deletion of the entire known-hosts file removes evidence and weakens verification for unrelated servers.

Understand which identity SSH is checking

Your login key proves something about you to the server. The server's host key proves something about the server to your client. Replacing your personal key does not solve a server-identity mismatch.

Clients remember host keys in a known-hosts store. The entry can be associated with a hostname, IP address or a hostname and nonstandard port. A server may also offer more than one host-key algorithm. Read the full warning to identify the host, key type and offending entry.

The OpenSSH client configuration manual documents host verification settings. Keep those settings explicit for important systems, especially when a team has many aliases and jump hosts.

Identify reasonable causes without assuming safety

A host key can change after a machine rebuild, migration or planned key rotation. DNS can also point a familiar name at a different server. An IP address reused by a cloud provider may now belong to a completely different machine.

Check the change record, server inventory and deployment activity. If no authorized change explains the warning, pause the connection and investigate. An attacker does not need to know your intended server name if routing or name resolution sends you elsewhere.

Keep a redacted incident note containing the destination, time, expected fingerprint and observed fingerprint. Do not include private keys, passwords or authentication tokens. The Text Diff can help compare sanitized host inventories, but it does not establish that a fingerprint is trustworthy.

Obtain the fingerprint independently

Use an authenticated provider console, an existing trusted administrator or another established management channel to obtain the new server's host-key fingerprint. That channel must not depend on the same unverified SSH connection.

On the verified server console, an administrator can inspect a public host-key file:

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

The file shown is the public half of a host key. Keep private host-key files confidential. Compare the complete fingerprint and algorithm with the client's warning, not just the last few characters.

Fetching a key over the network with a scanning utility can show what a destination presents, but it does not independently authenticate that destination. Treat such a scan as an observation, not as proof that it is safe to trust the observed key.

Inspect and replace the smallest relevant entry

After verification, locate the exact known-hosts record. OpenSSH's ssh-keygen manual documents searching and removing entries, including hashed hostnames.

ssh-keygen -F example.internal
ssh-keygen -R example.internal

These are illustrative commands for a host you administer. For a nonstandard port, the stored host identifier may use the bracketed hostname-and-port form; inspect the warning and actual entry before changing it. Back up the known-hosts file if your operational procedure requires it.

Reconnect only after the replacement key has been verified. Check that the new prompt matches the trusted fingerprint. Avoid a broad command that deletes every saved identity or bypasses verification for all future connections.

When DNS and aliases complicate the warning

A client alias can point to a different underlying hostname through SSH configuration. Review the effective target, port and jump-host settings. It is easy to investigate the wrong machine when a friendly alias hides a staging or production distinction.

If public DNS is relevant, inspect it with DNS Lookup. That helps confirm published records but does not establish the authenticity of the server behind them. Internal DNS and local host overrides may need separate investigation.

For fleets, consider an established host-certificate design or managed known-hosts distribution. Such approaches still need trusted certificate authorities, rotation procedures and revocation handling. They are operational designs, not shortcuts around identity verification.

Record the verified change

Update the inventory with the new fingerprint, host identifier, verification method and responsible change. Retain the old value as history if your system supports it. This makes the next unexpected warning easier to assess.

Test from a second authorized client if practical. A successful login proves access works; matching verified fingerprints proves that the intended identity was checked. Keep these two outcomes separate in the change record.

If several teammates see different fingerprints at the same time, compare their actual destinations and network paths. Do not merge those observations into one approved key change until the discrepancy has an explanation.

Reconnect with a reason, not just a cleared warning

Verify the new host identity independently, update only the relevant saved entry and preserve checking for future sessions. If the warning appeared during a connection through a bastion, also review SSH Agent Forwarding Risks.