If you spend enough time managing Linux servers, you will eventually type an SSH command and get hit with a massive wall of text screaming at you in all caps.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The SSH client refuses to connect, tells you the host key verification failed, and aborts the process entirely.
The warning is designed to look like a severe security breach. It is the only defense SSH has against a man-in-the-middle attack. In reality, nobody is hacking you. You probably just reinstalled your server.
Why This Warning Appears
When you connect to a server for the first time, your SSH client downloads the server's public identity key (usually an ECDSA or ED25519 fingerprint). It asks if you trust the fingerprint. When you type yes, your client saves that exact fingerprint into a local file called known_hosts.
The next time you connect to that IP address, your client checks the known_hosts file. If the server presents the same fingerprint, the connection proceeds silently.
If the server presents a different fingerprint for an IP address you already saved, the client panics.
This mismatch happens for two reasons.
The first is an actual man-in-the-middle attack. You are on a public Wi-Fi network and a malicious user is intercepting your traffic, pretending to be your server. Since they lack your server's actual private identity key, they present a fake fingerprint. Your client notices the mismatch, blocks the connection, and saves you from handing over your password.
The second reason is that you rebuilt the server. You destroyed an old DigitalOcean droplet and spun up a new one, and DigitalOcean assigned the exact same IP address to the new droplet. Or you wiped the OS on your Raspberry Pi. When an operating system is freshly installed, the SSH daemon generates brand new identity keys. The IP address stays the same, but the fingerprint changes. Your client assumes you are under attack.
How to Fix It
If you know you rebuilt the server or rotated its keys, you just need to tell your SSH client to forget the old fingerprint.
The warning message actually tells you exactly which line in your known_hosts file is causing the problem. It looks like this:
Offending ECDSA key in /Users/yourname/.ssh/known_hosts:14
You can open that file in a text editor and delete line 14 manually. Alternatively, you can use ssh-keygen to scrub the IP address for you.
Run this command, replacing the IP address with your server's IP:
ssh-keygen -R 192.168.1.50
This removes all entries matching that IP address from your known_hosts file.
The next time you run your SSH command, the client will treat the server like a brand new connection. It will show you the new fingerprint, ask you to type yes, and save the new identity.
Disabling the Warning
If you maintain a dynamic testing environment where servers are destroyed and rebuilt on the same IP addresses constantly, clearing the known_hosts file manually gets tedious.
You can force SSH to ignore fingerprint changes for a specific connection by passing two flags:
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@192.168.1.50
This forces the client to accept any host key and writes the "saved" key to the null device, throwing it away immediately.
Only use this for automated scripts inside a secure local network. Using it to connect to production servers over the public internet completely disables SSH's primary defense mechanism against interception.