“Remote Host Identification Has Changed”
Every SSH client remembers the cryptographic identity of each server it has connected to. When the key it is offered stops matching the one it remembers, it refuses to connect and prints a warning with more capital letters than most software will ever use. The warning is not a bug and it is not the client being difficult. It means one of exactly three things, two of them mundane and one of them serious, and the whole point of the check is that your client genuinely cannot tell which. That determination is yours to make, and it takes about a minute.
Written by the GateShell team at Hefty Innovations
Step by step
- 1
Do not clear the warning yet
Every instruction you will find online tells you to delete the offending line from known_hosts, and every one of those instructions works, in the sense that the warning goes away. That is also precisely what an attacker performing a machine-in-the-middle attack needs you to do. Clearing the stored key is the last step, not the first. Nothing is broken while the warning stands, and you lose nothing by spending sixty seconds on the question first.
- 2
Work out whether you changed something
Start with the boring explanation, because it is almost always the right one. Did you rebuild or reimage this server? Restore it from a snapshot? Move the DNS name or the elastic IP to a different machine? Reinstall the SSH server package, or let a config-management tool regenerate host keys? Each of these legitimately produces a new host identity. If you can point to one of them with a timestamp that lines up, you have your answer.
- 3
Rule out the address having moved
The second mundane cause catches people on home and cloud networks. If you connect by IP and that address is handed out by DHCP or reassigned from a cloud pool, you may simply be reaching a different machine than last time — the warning is accurate, and the server you meant is elsewhere. Connecting by a stable hostname rather than a raw IP removes this class of confusion permanently, and is worth doing regardless.
- 4
Verify the fingerprint over a channel that is not this one
This is the step that actually resolves it, and the one people skip. Get the server's current fingerprint from somewhere other than the connection you are suspicious of: your cloud provider's console, the VM's serial console, an existing session on another machine, or a colleague reading it out. Run ssh-keygen -lf on the server's public host key file to print it. Compare against what your client is showing you. If they match, the change is real and benign. If they do not, stop, and treat the network path as hostile.
- 5
Only now, update the stored key
Once verified, remove the remembered entry so the new identity can be pinned in its place. In GateShell this is a per-server action rather than an edit to a shared file, so clearing one server's key cannot accidentally reset trust for the others — which is a real hazard of the ssh-keygen -R workflow when muscle memory takes over. The next connection pins the new key, and subsequent warnings mean something again.
- 6
Understand what the pin is protecting
Host-key verification is the only thing standing between you and a machine-in-the-middle on an untrusted network, and phones live on untrusted networks constantly. Your keys and password are only safe from an impostor server because your client checks the server's identity before offering them. Trust-on-first-use means the first connection establishes the baseline and everything after is checked against it. A user who clears every warning reflexively has turned that protection off without noticing.
Frequently asked questions
Is this warning always an attack?+
No, and in practice it rarely is. A rebuilt server, a restored snapshot, a regenerated host key, or a reassigned IP address all produce it legitimately. The reason the warning is so severe is that the client cannot distinguish those from an attack — only you can, by verifying the fingerprint out of band.
What does trust-on-first-use actually mean?+
It means the very first connection to a server is unverified, and whatever key is offered then becomes the remembered baseline. Every connection after that is checked against it. The model has a real weakness — a machine-in-the-middle present at that first connection gets pinned instead of the real server — which is why verifying the fingerprint on first connection matters for anything sensitive.
How do I get the real fingerprint to compare against?+
Run ssh-keygen -lf on the relevant public host key file on the server, typically under /etc/ssh/. Reach it through something other than the suspect connection: a cloud provider's web console, a serial console, or an existing session from a machine you trust. The comparison is only meaningful if the two channels are genuinely independent.
Why not just delete known_hosts and start over?+
Because it discards the baseline for every server at once, so no warning can fire for any of them until each is pinned again. It converts a specific, actionable alert into a blanket loss of protection. Clear the single entry for the single server in question.
Does this apply to Mosh connections too?+
Yes. Mosh bootstraps over SSH, so the host key is verified during that bootstrap exactly as it would be for a plain SSH session. The encrypted UDP transport takes over afterwards, but it does not bypass the identity check.
Does connecting through a jump host change any of this?+
No, and this is worth knowing. Each hop is verified independently, so the target server's host key is checked on its own terms even though you are reaching it through a bastion. Verification is not delegated to the intermediate host.
Try it in GateShell
GateShell is a zero-backend SSH client for iPhone, iPad, and Mac, with no vendor cloud, no accounts and no telemetry. Everything above works out of the box.
Guide reflects GateShell's shipped features as of September 2026. Steps assume basic familiarity with SSH and the command line; server-side commands may vary by distribution. All product names, logos, and brands are property of their respective owners.