SSH Host Key Changed? Verify It Before Fixing known_hosts

You run ssh to connect to a VPS, pull from a Git remote or deploy an application. Instead of a login prompt, your terminal stops with “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!”

The tempting fix is to delete a line from known_hosts and try again. Sometimes that solves the connection problem. It also discards the very evidence SSH was using to detect a possible impostor.

The safe rule: verify the server's replacement host-key fingerprint through a trusted source separate from the connection that raised the warning. Only then remove the outdated entry and reconnect. A changed key can be legitimate, but the warning alone cannot establish why it changed. GitHub's SSH troubleshooting guidance gives the same conservative advice.

This guide covers the OpenSSH client used on Linux, macOS and Windows. Commands are illustrative unless they use the real github.com host; replace the sample hostname with the server you actually administer.

Why SSH remembers a server's key

SSH has two different identity checks, and confusing them is how this problem becomes frustrating:

• The server's host key lets your SSH client check which server it is speaking to. The public half is associated with a hostname in the client's known_hosts database, commonly ~/.ssh/known_hosts.
• Your login key (for example, ~/.ssh/id_ed25519) helps the server authenticate you. It is separate from the server's host key. A valid login key does not prove that the destination server is genuine.

During SSH's connection setup, the server demonstrates possession of its host private key. The client checks that identity against a previously trusted host key, a trusted host certificate or another configured trust mechanism. For ordinary first-time connections, many setups use trust on first use: you approve a fingerprint once, and SSH checks subsequent connections against the saved identity. The SSH architecture standard, RFC 4251 , describes both the value and the first-connection limitation of this approach.

A fingerprint beginning SHA256: is a compact representation of a public key. It is not a password, and it is not enough to establish ownership unless you compare it with a trustworthy reference.

Unknown host or changed host? Read the message carefully

There are innocent reasons for a mismatch: a VPS was rebuilt, host keys were regenerated, a server or address was reassigned, or an administrator rotated keys. There is also a serious possibility: another system is impersonating the expected server. Oracle's OpenSSH administration guide documents both classes of explanation. The error is a warning, not a verdict that your server has been hacked.

A safe five-step workflow for a changed host key

1. Record the exact host, port and key type

Before changing anything, note the hostname (or IP address), SSH port and key algorithm shown in the error, such as ED25519, ECDSA or RSA. Also note the newly presented fingerprint. This is evidence of what answered your connection, not yet proof of the intended server's identity.

The hostname matters because ssh can have multiple entries, including hashed names, IP addresses and separate entries for non-default ports. If you connected to server.example.org on port 2222, its known_hosts lookup uses the bracketed form [server.example.org]:2222.

2. Inspect the saved identity without deleting it

For a normal connection on port 22, run:

ssh-keygen -F server.example.org -l

For an SSH server on port 2222:

ssh-keygen -F '[server.example.org]:2222' -l

-F searches known_hosts, including entries whose hostnames were hashed. -l asks for the fingerprint. These are inspection commands; they do not repair or replace trust. If your SSH configuration uses a nonstandard UserKnownHostsFile or HostKeyAlias, check the effective configuration before assuming the default lookup is complete. See the OpenSSH `ssh-keygen` manual and client configuration reference .

3. Verify the replacement fingerprint independently

This is the important part. Obtain the expected public host-key fingerprint from a channel you already trust:

• Your own Linux server: use a cloud provider's authenticated console, serial console or other established management route that does not depend on the disputed SSH connection. From that server's console, check the public host key:

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

That path is the common OpenSSH Ed25519 host public-key path on Linux and other Unix-like servers; an administrator may configure different key files. Match the key algorithm shown in the client warning. Do not read or send the private host-key file to someone else.

• A managed service: use its authenticated, official documentation or a verified change announcement. For GitHub, compare against GitHub's published SSH host-key fingerprints .
• A company or shared server: ask the administrator through a known contact channel to confirm the expected fingerprint and whether a key rotation occurred. A message coming from the suspicious SSH connection is not an independent confirmation.

Compare the full fingerprint and key type. If you cannot obtain an independently trusted reference, do not override the warning. Investigate the server's change history, host configuration, DNS and network path, or contact your provider.

4. Remove only the now-obsolete host entry

Do this only after the new host key has been verified. For a normal connection:

ssh-keygen -R server.example.org

For a custom SSH port:

ssh-keygen -R '[server.example.org]:2222'

ssh-keygen -R removes saved keys associated with the specified host identity, including hashed entries. It does not verify the new key. If you have a customised known_hosts path, use the manual's -f option and keep a backup before editing. A relevant IP-address entry or separately configured trust store may also need investigation; avoid deleting everything indiscriminately. OpenSSH documents the exact scope of `-R`.

5. Reconnect and compare once more

Reconnect normally:

ssh [email protected]

Or specify the alternate port:

ssh -p 2222 [email protected]

When SSH presents a new fingerprint, compare it to the one you verified through the independent channel. Approve the prompt only if they match. Your client can then save the verified public host key. If the newly presented fingerprint differs from the independently checked value, stop instead of retrying with increasingly permissive settings.

A successful repair is not merely “the warning disappeared”. It is a connection to a server whose host identity you have confirmed.

Why the popular shortcuts are unsafe

A search result may suggest one of these fixes:

ssh -o StrictHostKeyChecking=no [email protected]

Or it may recommend collecting a fresh key with ssh-keyscan and immediately appending the result to known_hosts.

Neither action authenticates the new server for you. OpenSSH's client configuration manual says StrictHostKeyChecking=no can allow changed host keys subject to restrictions. Its `ssh-keyscan` manual explicitly warns that the tool cannot establish the authenticity of retrieved keys: an attacker able to intercept the scan can supply an impostor's key. ssh-keyscan can be useful for gathering keys, but only an independent comparison turns collected data into a trusted identity.

StrictHostKeyChecking=accept-new is a different trade-off: it can automatically accept previously unknown host keys, but it still rejects changed host keys. That can suit controlled automation with an understood first-use risk; it is not a way to verify a new machine on an untrusted network. For CI pipelines and managed fleets, provision trusted host keys or use an appropriate host-certificate trust model rather than silently learning any key offered during every run.

A concrete example: an SSH warning from GitHub

When a Git client connects over SSH to github.com, it checks GitHub's server identity before user authentication. GitHub publishes an official list of RSA, ECDSA and Ed25519 host-key fingerprints. Compare the algorithm-specific fingerprint shown by SSH against the current official list —do not rely on a value copied from an old forum reply.

GitHub actually rotated its RSA SSH host key in March 2023 , a useful example of a real service changing a key. An old incident announcement is context, not evidence that today's unexpected warning is harmless.

After validating the current fingerprint and updating the relevant old entry, GitHub's documented connection test is:

ssh -T [email protected]

A successfully authenticated GitHub SSH test reports that shell access is not provided. GitHub notes that the test can still exit with status code 1, so interpret the message rather than assuming every non-zero exit code means a broken host-key check. See GitHub's test instructions .

Can server administrators rotate keys without surprising users?

Often, yes. OpenSSH supports UpdateHostKeys, which lets a server that has already authenticated with a trusted key advertise additional host keys for later use. Under the documented prerequisites, the client can learn these extra keys before the original key is removed. This helps planned rotation, but it cannot retrospectively prove a replacement key is legitimate after trust has already been lost. See the OpenSSH `UpdateHostKeys` reference .

If you manage a server, plan the rotation, distribute independently verifiable fingerprints and preserve a trusted transition path where possible. If you only use the server, demand evidence of the new identity before changing the client-side record.

The decision to remember

An SSH host-key warning is a server-identity problem, not a prompt to regenerate your personal SSH key or clear all SSH settings. Check exactly which key changed, obtain a matching fingerprint independently, and then update only the stale entry.

If the fingerprint cannot be verified, the safe outcome is to leave the warning in place while you investigate. An extra minute spent checking a fingerprint is preferable to teaching your SSH client to trust whichever machine happens to answer.

Primary sources and further reading

• OpenSSH `ssh-keygen` manual — host-key lookup, fingerprints and targeted entry removal.
• OpenSSH `ssh_config` manual — strict checking, trust files and graceful host-key updates.
• OpenSSH `ssh-keyscan` manual — why collecting a key is not the same as authenticating it.
• RFC 4251: SSH Protocol Architecture — the host-key trust model and first-use risk.
• GitHub's SSH troubleshooting and host-key documentation — provider-specific handling and the current fingerprint list.