How can I confirm that this SSH warning is not a genuine man in the middle attack? “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!”

Question

I'm a new to this kind of stuff and want to rule out man-in-the-middle attack.

I'm connecting from a Windows 10 PC to a Raspberry Pi 4 via SSH, within my LAN and I get this message. I'm the sys admin, so there's no one to check with.

I found a lot of posts on how to fix the issue, but I want to know what I should do to actually rule out (or confirm) an attack before fixing it.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 ECDSA key sent by the remote host is
SHA256:0xgFiU5j9W2WgyurDOgORf+qeFQoHf0YE6G92KnrduY.
Please contact your system administrator.
Add correct host key in C:\\Users\\JamesAlesi/.ssh/known_hosts to get rid of this message.
Offending RSA key in C:\\Users\\JamesAlesi/.ssh/known_hosts:2
ECDSA host key for 192.168.1.123 has changed and you have requested strict checking.
Host key verification failed.

Answer 1

Generally, the approach you take is always the same: you verify the fingerprint of the key via a channel that the attacker cannot possibly have manipulated.

For example, in my old university, you could go to the computing center front desk and get a flyer with a list of fingerprints of all the important keys and certificates. If it's a server of a friend you know personally, you can call them and ask them to read the fingerprint to you. If it's a hosted, managed server, some of the more security minded hosting providers might offer to mail the fingerprints to you.

The gist is: IFF you have reason to believe your network connection is compromised, then try to obtain the fingerprint without using the network.

For your Raspberry Pi, there are several very simple options:

• Just connect a network cable from your computer straight to the Raspberry Pi. Boom: there is no "middle" anymore where someone could mount a Man-in-the-middle attack.
• Connect to the serial console of the Pi from your PC and log into the console directly. Boom: there isn't even a network anymore.
• Plug a USB keyboard and HDMI monitor into your Pi and log into the console directly.
• Take out the SD card (or USB stick or whatever your boot medium is), mount the ext2 filesystem on your PC (if you don't run Linux, you might need extra software for that, or you can boot into a Linux LiveCD), and check the key in /etc/ssh/ssh_host_ecdsa_key.

This answers the more specific question about how to verify the host key. Now to your more general question:

I'm a new to this kind of stuff and want to rule out man-in-the-middle attack.

In order to mount a man-in-the-middle-attack on your LAN, the attacker needs physical access to your LAN infrastructure. So, if you want to rule out a man-in-the-middle attack, you can literally just trace your cables and look for a "man in the middle", i.e. a device that you don't recognize. Although be careful: such devices can be tiny and well hidden.

You can also look for signs of a break-in on the lock of your door, or other ingress points of your home (windows, etc.)

Now, you can run a plausibility analysis: what is more likely, that someone broke into your home and installed a device in your LAN without you noticing, just to see what you are doing with your Raspberry Pi? Or is it more likely that 192.168.1.123 was assigned to a different device before (or that you updated or re-installed or re-configured your Pi) and the old key was still cached on your PC?

If we're talking about a WiFi, though, then a MitM attack does not require physical access. So, it becomes much more likely that someone would be able to mount such an attack without you noticing. However, the question still remains: what does the attacker want with sniffing the connection between you and your Pi?

Likewise, if any device on your LAN is also connected to a different network (a WiFi, a neighborhood network, the Internet), then this device can be compromised via that network, and thus give an attacker access to your LAN.

As mentioned in a comment above, a compromised Raspberry Pi is a valuable thing, but any competent attacker would know to compromise it in a way that doesn't change the host key.

Answer 2

When you connect to any host for the first time, SSH saves its identification info. If this identification changes in the future, it displays this message.

This could happen for example after reinstalling target system, replacing it with another one with the same IP/hostname you use to connect or after regenerating system's server SSH keys. If this sounds like something you did recently, that's the reason.

It could as well be someone intercepting your connection (and actually sending their identification), but in a LAN it's unlikely.

Answer 3

Log into the Raspberry Pi from the machine you normally log into it with. Note the key. Confirm that the fingerprint is correct.

If you never set up any secure way to log into the Raspberry Pi from any location, then you don't have one. Next time, do so when you set the machine up. For example, take a photograph of the key fingerprint from the console when you're setting the OS up.

Answer 4

Have you had other devices on your local network that you have connected with ssh to, like other Pi:s or some regular *nix computers?

If you use DHCP, an IP address assigned (time-limited, in form of a DHCP "lease") to one device may get reused for another device later. If you have connected with ssh to one device, ssh remembers the host key for that IP address. When a new device get the same IP address assigned and you try connecting with ssh, you get the above error.

Many DHCP servers try to assign "quasi-permanent" addresses based on MAC (the ethernet hardware address) of the device asking for an IP address, but it's not perfect - for example if every IP address in the range available for DHCP is used already some have to be reused. Or if the router / home server / whatever device you use for DHCP is reset or replaced.

Answer 5

You are not being hacked.

Why would anyone want to “man-in-the-middle” access to a Raspberry Pi on a personal LAN anyway?

“…I want to know what I should do to actually rule out (or confirm) an attack before fixing it.”

The chances of someone “man-in-the-middle” attacking you within your LAN via a Raspberry Pi are slim to none. What is the benefit of them doing this if they somehow breached your LAN and you have a nice Windows machines they can get into?

The main reason anyone does “man-in-the-middle” is to capture data — such as credentials and such — and then go wild with them. They get some credentials for a Raspberry Pi and that leads to what? Unless your Raspberry Pi is somehow doing financial transactions and such, but I doubt it.

The more likely scenario is you re-installed the OS on the Raspberry Pi which would change the identification signature and end up in a scenario such as what you are dealing with. Because that is typically why an identification mismatch like this happens; something changed the identification.

In the non-Raspberry Pi world this can happen if you swap a system disk from one machine to another — such as in a hardware upgrade and such — and it even happens more often with VMs and such where installing/blowing away systems is very easy.

As for somehow giving you some kind of list of ways you can confirm on your own, honestly past the common sense assessment I outline that’s not really possible.

Answer 6

Most of the time, especially when dealing with relatively ephemeral devices like Raspberry Pis, this message is benign; perhaps you put a different SD card in, or reinstalled the OS, or assigned the same IP to a different device, or any one of about a dozen actions that can result in a new host fingerprint. However, I suggest you do not settle for "most of the time" when it comes to host fingerprints, since they are so easy to verify.

As others have already correctly pointed out, you need to verify the host key fingerprint via a trusted channel. In other words, don't just SSH to the Pi and run the commands below, as that would be vulnerable to the same (potential) MitM attack you are trying to rule out. In this case, I'd suggest you use the Pi's HDMI connection, or serial, or some other trusted connection, to verify the host fingerprint.

Now, to actually verify the fingerprint, you'll need a shell on the Raspberry Pi. Type ssh-keygen -l (small letter 'L') and press [Enter]. That will prompt you for the filename of the key. The key you want should be in /etc/ssh (the default path it suggests does not contain the system's host keys; ignore those, here). Look for the ECDSA key, since that is what your SSH client reported connecting with. You'll get the same result whether you use the public key (.pub extension) or the private key (no extension), but unless you are logged in as root, you'll only be able to read the public key.

ssh-keygen -l followed by inputting the correct private key's filename will output that key's fingerprint. It should look something like this:

pi@raspberrypi:~$ ssh-keygen -l
Enter file in which the key is (/root/.ssh/id_rsa): /etc/ssh/ssh_host_ecdsa_key.pub
256 SHA256:0xg...[redacted]...rduY. root@pi (ECDSA)

(That filename may or may not be correct for your Raspberry Pi. Check with ls -l /etc/ssh first.)

You would then carefully compare the fingerprint your system outputs with the one you got from ssh earlier. If they match, then the connection is verified, and you can safely update your local ~/.ssh/known_hosts accordingly. If they do not match, then something weird is going on that would require further investigation.

Answer 7

I want to know what I should do to actually rule out (or confirm) an attack before fixing it.

You need to use a 100% trusted channel to receive this information.

The best approach is to log in to the system directly - i.e: plug in a keyboard and monitor, or use a serial console if appropriate.

Once you have logged in, run one of the following commands:

ssh-keygen -l -f <( ssh-keyscan 127.0.0.1 )

or:

for k in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -l -f "${k}"; done

This will:

• ssh-keyscan - Connect to the local system's SSH server, and request the host keys
  • You can swap 127.0.0.1 for a remote host too if you need... though doing this operation remotely requires absolute trust that the remote is who it says it is, and that everything between you and the remote can be trusted.
  • Using 127.0.0.1 will route the connection via the loopback interface, and will communicate directly with the local system. (ignoring potential iptables rules to re-route the traffic)
  • In the case of an attack, using localhost may actually redirect you to another host (using /etc/hosts), so avoid using it.
• ssh-keygen - Show the fingerprints (-l) of the keys in the supplied file (-f ${file})
  • Using with ssh-keyscan 127.0.0.1 (i.e: option 1) will actually connect to the running daemon, and query the keys as any other client would
  • Using with files in the local filesystem (i.e: option 2) may be considered the slightly "more secure" approach, but that doesn't consider mis- or mal-configuration of the server, with keys located elsewhere... You'll need to go digging for the correct keys.

Then, once you have the fingerprint(s), carefully compare them with the key being offered by the remote system you're trying to connect to (i.e: SHA256:0xgFiU5j9W2WgyurDOgORf+qeFQoHf0YE6G92KnrduY in your example).

If the fingerprint does not match, then you have confirmed that an attack is underway, and you're not talking to the system you think you are.

If the fingerprint matches, then great! Resolve the issue using ssh-keygen -R ${hostname}, and continue on your way.

Notes:

• The standard caveat that if a system is comprimised, then you may have to consider the host key comprimised too... in which case you'll have no way of knowing.
• It might be possible to cause a hash collision and present the same fingerprint for two different keys... in which case you'll have no way of knowing.
• Any network-based traffic can be altered or redirected using iptables... if you suspect that a system is comprimised, it might be a good idea to check there too.

---

It is impossible to do this without having a 100% trusted channel of communication. In your case, you can log in to the Pi, and retrieve the keys directly. In other situations, you might need to "take the word of a colleague"... Be careful where you put your trust.

---

I'm a new to this kind of stuff and want to rule out man-in-the-middle attack.

On a small local network, it's very likely that you're talking to the system you think you are.

If the remote IP address is in your subnet, and there aren't any other unknown or suspicious devices present in your network, then it will be difficult to construct a MITM attack. For further certainty, try removing all other devices, or even create a point-to-point link between your computer and the remote computer (though addressing and DHCP can become problematic in this situation).

If you suspect your router is not trustworthy, then bear in mind that it can advertise routes and names (DNS / mDNS / WINS) to your system, that your system will generally just trust implicitly. If internet can be taken out of the equation, then such routing / redirection tricks can't be played unless they are facilitated internally.

... "Trust in computing" is a really big topic, and there are so many avenues that we could send you down here... I encourage you to ask / read / play / etc... it's the best way to learn.

---

As has already been discussed in other answers... the most likely situation you find yourself in here is either:

1. You reinstalled the operating system on your Raspberry Pi
2. Your DHCP server handed out a lease that was previously given to another host that you used ssh with, and which was recently given to your Raspberry Pi

---

Typically people will accept the fingerprint displayed on first connection and be content with that into the future.

On particularly sensetive systems, you'll want to confirm the fingerprint is exactly correct on the first connection.

If the fingerprint changes, then something about the host has changed - for example an imposter or a re-install.

Answer 8

The message basically means that you are connecting to a different computer at a specific ip/address then before.

Why can this happen besides MITM? Possibly the computer was reinstalled. Possibly you put a different computer on the IP and totally expect the message.

In the context of a connection routed entirely through your LAN, the odds of an actual attack instead of a benign reason are very low.