01
Identify which identity is being checked
A host key identifies the server. Your private login key identifies you to that server. Generating a new client key or adding your public key again will not resolve a server identity mismatch.
Check the effective hostname and port, especially when an alias, VPN, load balancer, or recently reassigned address is involved. Keep the warning and the stored entry available while investigating; deleting the evidence first makes an unexpected change harder to explain.
ssh -G app-server
ssh-keygen -F '[server.example.com]:2222' -f ~/.ssh/known_hosts02
Obtain the expected fingerprint independently
Use the provider console or a separately authenticated administrator channel to inspect the server public host key. On an Ed25519 Linux server, the command below prints its SHA-256 fingerprint. Confirm that this is the machine and key type offered by the connection you are investigating.
A network key scan alone cannot establish trust: it reports the key presented on that network path. For managed services, consult the service operator’s authenticated fingerprint publication. GitHub publishes its own fingerprints; those values apply to GitHub, not to an unrelated server.
# Run through a trusted server console, not the unverified SSH path.
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha25603
Compare a candidate without installing it
Save a candidate key separately, inspect its fingerprint, and compare it with the independently obtained value for the same key type. The example uses an Ed25519 server and nondefault port; substitute the actual endpoint. Keep the candidate outside your active known_hosts file until verified.
In our lab, the rotated server initially produced a host identification warning and refused the connection. A scan of its replacement Ed25519 key matched the fingerprint read through the isolated container console. This comparison established the intended replacement for that controlled test.
candidate=$(mktemp)
ssh-keyscan -T 5 -t ed25519 -p 2222 server.example.com > "$candidate"
ssh-keygen -lf "$candidate" -E sha256
# Compare the fingerprint with the trusted console result before continuing.04
Replace only the verified endpoint
After verification, remove the stale entry for that exact host and port, append the verified candidate, then reconnect with strict checking. Review whether the same machine is also stored under an IP or another alias; do not erase the whole trust file.
Our next connection succeeded while StrictHostKeyChecking remained enabled. The fix changed the trusted identity for the confirmed endpoint, rather than teaching the client to accept arbitrary replacements.
# Continue only after the independent fingerprint comparison matches.
ssh-keygen -R '[server.example.com]:2222' -f ~/.ssh/known_hosts
cat "$candidate" >> ~/.ssh/known_hosts
rm "$candidate"
ssh -o StrictHostKeyChecking=yes -p 2222 developer@server.example.com05
Stop when the change cannot be explained
A planned rebuild or documented rotation can explain a new key. An unexplained mismatch requires investigation of the endpoint, DNS, and access path before credentials are offered. Do not use StrictHostKeyChecking=no as the routine repair.
Record the old and new fingerprints, the verified source, and the reason for replacement. That small change record is useful the next time an address is recycled or a teammate sees the same warning.
Know the limits
Tested with an isolated OpenSSH 9.2p1 server whose Ed25519 host key we deliberately rotated. No customer incident is implied. Examples assume ordinary known_hosts entries; SSH host certificates and centrally managed trust need their own verification process.
Sources & further reading
A technical publication by CoreTrailKit.
Browse all articles