You rebuilt a Linux server and kept its hostname and IP address. Now `ssh` to it aborts with `WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!` and refuses to connect. Why does a rebuild trigger that, and what is the correct way to clear it?

## What `known_hosts` is for SSH authenticates in both directions. Your key proves who you are to the server; the server's **host key** proves the server is the machine you meant to reach. On the first connection the client has nothing to compare against, so it shows the fingerprint and asks you to accept it, then writes the key into `~/.ssh/known_hosts` next to the hostname and address you used. Every later connection compares the offered key against that record. This is trust-on-first-use: the first connection is the weak point, and every subsequent one is protected. The host key pair lives on the server in `/etc/ssh/`, typically `ssh_host_ed25519_key` plus `ssh_host_rsa_key` and their `.pub` counterparts. They belong to the machine, not to any user. ## Why a rebuild breaks it Fresh host keys are generated the first time sshd starts on a new installation — by the package install, by `cloud-init`, or by whatever image pipeline you use. Reinstalling, reimaging, restoring from a different snapshot, or replacing an instance behind the same DNS name all produce a machine with the same *name* and a different *identity*. The client sees a mismatch and refuses, printing the offending line number: ``` @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Offending ECDSA key in /home/alice/.ssh/known_hosts:12 ``` Note what else it does: it disables password authentication for that connection. If you really were talking to an impostor, the dangerous outcome is not the failed session — it is typing your password into it. Refusing to send credentials to an unverified host is the whole point of the check. ## The correct clearing procedure The legitimate case and the attack look identical from the client, so the step you must not skip is verifying the new fingerprint through a channel that does not depend on the connection you distrust: - read it from the instance's console output or serial console, where `cloud-init` prints the host key fingerprints on first boot; - or run `ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub` on the box via that console; - or take it from the config-management record of what the image installed. Then remove the stale entry and reconnect: ``` ssh-keygen -R server.example.com ssh-keygen -R 10.0.4.17 ssh [email protected] ``` `ssh-keygen -R` rewrites `known_hosts` and keeps a `.old` backup. It works even when entries are hashed — on Debian and Ubuntu the file is stored with hashed hostnames by default, so you cannot find the line by grepping for the name, but `ssh-keygen -F server.example.com` will locate it and `-R` will delete it. Remove the address entry too if you sometimes connect by IP, otherwise the warning returns the next time you do. Deleting the whole `known_hosts` file also "works" and is worth calling out as the wrong habit: it throws away every other host's pinned identity, silently downgrading all of them to trust-on-first-use again. ## At fleet scale, stop the churn instead of clearing it If machines are cattle, this warning fires constantly, and a team that sees it every day stops reading it — which is precisely the failure mode an attacker needs. Two durable answers: - **Distribute `known_hosts`.** Collect keys with `ssh-keyscan` at build time and ship a managed system-wide `known_hosts` through config management, so clients never rely on first-use trust. The value depends on `ssh-keyscan` running somewhere you trust, ideally on the build network right after provisioning. - **Sign host keys with a CA.** Issue each host a certificate over its host key, and give clients a single `@cert-authority` line for the CA. Any correctly signed rebuild is then trusted immediately, and the client file stops changing at all. This is the same mechanism used in the other direction for user certificates, and it is the answer that scales. What is *not* an answer is blanket-disabling host verification in automation. It converts every SSH session on the fleet into an unauthenticated channel, and it is usually done in exactly the places — deployment pipelines with privileged credentials — where the consequences are worst.