The warning in full — and why it looks so alarming
Here is the exact message that causes so much panic:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 fingerprint for the RSA key sent by the remote host is
SHA256:iVsX92Vzwqr/Uic3LwL24Wa+eUu2gTobcWb59/tUdG4.
Please contact your system administrator.
Add correct host key in C:\Users\Paul/.ssh/known_hosts to get rid of this message.
Offending RSA key in C:\Users\Paul/.ssh/known_hosts:1
Host key verification failed.The capitals, the exclamation marks, the row of @ symbols — it is designed to get your attention. And in certain situations it absolutely should. But in the context of connecting to your own router on your own home or office network, it almost always means something completely harmless has happened. Let us go through it properly.
What SSH keys actually are — the plain English version
When two computers connect via SSH for the first time, the server — in this case your router — introduces itself with a unique digital identity called a host key. Think of it like a passport photo. Your computer takes a copy of that photo and stores it in a file called known_hosts.
Every time you connect to the same address again, your computer checks — does the face match the photo I have on file? If yes, connect normally. If no, refuse to connect and show the warning.
Fig 1. SSH saves the router's key on first connection. If the key changes — because the router was reflashed or reset — SSH refuses to connect and shows the warning.
Breaking down every line of the warning
The @ symbols and "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED"
This is SSH telling you that the key your router is presenting today is different from the key it presented last time you connected. The @ border is just to make sure you see it — it is a visual alarm bell, nothing more.
"IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY"
This is the line that causes the most panic. SSH is being honest — in theory, a changed key could mean someone has intercepted your connection and is pretending to be your router. This is called a man-in-the-middle attack. On a public network — a coffee shop, a hotel, an airport — this would be a genuine concern. On your own home or office network, connecting to your own router, this is essentially impossible. Nobody has physically replaced your router with a different one.
"It is also possible that a host key has just been changed"
This is the actually true explanation in almost every case. The router was reflashed with new firmware, or reset to factory defaults, or it is a different router at the same IP address. When any of these happen, the router generates a completely new identity key. Your computer sees a different key at the same address and triggers the warning.
"The fingerprint for the RSA key sent by the remote host is SHA256:..."
This is the new key's fingerprint — a shortened version of the full key, like a summary. You could theoretically compare this to the router's documented fingerprint to verify it is genuinely your router. In practice, for a home or office router you own, this level of verification is not necessary.
"Offending RSA key in C:\Users\Paul/.ssh/known_hosts:1"
This tells you exactly where the old key is stored and which line it is on. Line 1 of the known_hosts file contains the old key for 192.168.1.1. This is useful — it tells us exactly what needs to be removed.
"Host key verification failed"
SSH refused to connect because the key does not match. This is the security system working correctly — it is protecting you from connecting to something that is not what it claims to be. We just need to tell it that the change is expected and legitimate.
When should you actually be concerned?
On your own home or office network, connecting to your own router — almost never a genuine attack. The key changed because you reflashed, reset, or replaced the router.
On a public network — a hotel, coffee shop, airport, conference venue — take it more seriously. If you did not recently change anything about the device you are connecting to, an unexpected key change on a public network is worth investigating before proceeding. In that situation, do not dismiss the warning without understanding why the key changed.
The fix — one command
The fix removes the old key from your known_hosts file. SSH will then treat the next connection as a first connection and save the new key.
1 Remove the old key for your router's IP address:
# Run this in PowerShell (Windows) or Terminal (Mac)
# Replace 192.168.1.1 if your router uses a different IP address
ssh-keygen -R 192.168.1.1
# You will see:
# Host 192.168.1.1 found: line 1
C:\Users\Paul/.ssh/known_hosts updated.
Original contents retained as C:\Users\Paul/.ssh/known_hosts.old
# The old key has been removed
# known_hosts.old is a backup of the previous file — safe to ignore2 Connect again as normal:
ssh root@192.168.1.1
# You will see a new prompt asking you to confirm the new key:
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
ED25519 key fingerprint is SHA256:6C9MhzI1qWP7McUTTt8OwJA00IFRXhk+SXYeAOxswbo.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
# Type: yes and press Enter
Warning: Permanently added '192.168.1.1' (ED25519) to the list of known hosts.
# The new key is saved. You will not see this warning again
# unless the router's key changes againThat is the entire fix. Two commands. The second time you connect after this, SSH goes straight through with no warnings.
What just happened — the full sequence explained
Here is the complete sequence you went through, with every step explained:
## STEP 1 — First attempt, warning appears
ssh root@192.168.1.1
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED
Host key verification failed.
# SSH found a different key than expected — refuses to connect
## STEP 2 — Remove the old key
ssh-keygen -R 192.168.1.1
# Host 192.168.1.1 found: line 1
C:\Users\Paul/.ssh/known_hosts updated.
# Old key deleted from known_hosts file
## STEP 3 — Connect again
ssh root@192.168.1.1
The authenticity of host '192.168.1.1' can't be established.
ED25519 key fingerprint is SHA256:6C9Mhz...
Are you sure you want to continue connecting (yes/no)?
# SSH is treating this as a first connection — asking permission to save the new key
## STEP 4 — Confirm
yes
Warning: Permanently added '192.168.1.1' (ED25519) to the list of known hosts.
# New key saved. Connected. Done.Why does this keep happening?
You will see this warning every time the router generates a new key. The common causes are:
- Flashing new firmware — any firmware update or change wipes the old key and generates a new one
- Factory reset — holding the reset button restores defaults including a fresh key
- Connecting to a different router at the same IP — if you swap your router for a different one, the new router has a completely different key
- VPN software — some VPN clients assign IP addresses that conflict with your router's local address, causing confusion
Whatever the cause, the fix is always the same on your own network. Run ssh-keygen -R 192.168.1.1 (substitute your router's actual IP if different), then SSH in again and type yes. That is it. You will never need to do anything more complicated than this on a private network.
Also worth knowing — VPNs and local addresses
One thing worth mentioning that catches people out regularly. If you have a VPN running on your PC, it may route all your traffic — including local network traffic — through the VPN tunnel. Your router is at 192.168.1.1 on your local network. That address is not reachable through a VPN exit node somewhere else. The result is SSH simply cannot connect, or connects to something unexpected.
If SSH behaves strangely and you have a VPN running — turn the VPN off first, then try again. Most VPN clients have a setting called split tunnelling that lets local network traffic bypass the VPN, but it is often not enabled by default.