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.

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
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 has changed and you have requested strict checking.
Host key verification failed.
  • 9
    Did you reinstall the OS on your Pi since you last SSH'ed into it? May 12, 2020 at 13:34
  • 2
    The IP address assigned is dynamically assigned by DHCP; this one may have belonged to a different device the other day. One option to prevent this is to always assign the same IP address to the Pi (by configuring the router). May 13, 2020 at 8:37

8 Answers 8


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 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.

  • 21
    You don't always need physical access, though. For example, the OP might be running a vulnerable network router connected to the internet, or an exposed Wi-fi router, or the devices are using someone else's Wi-fi etc. But yeah, first thing to check is reinstall on the Pi or changing IP addresses.
    – Luaan
    May 12, 2020 at 7:07
  • 14
    The only situation where you'd need physical access to mount a MitM would be on an air-gapped LAN. As soon as the network is connected to the Internet, an attacker can compromise a device on the LAN and use it to hijack the connection (redirect packets for processing on a switch/router, spoof ARP, run their own DHCP server etc.).
    – TooTea
    May 12, 2020 at 9:11
  • 3
    "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 that someone broke into your home and stole your RPi, other computers, TV, jewelry, and other valuable items. Unless you're a person of significant interest to someone with breaking and entering resources and technical knowledge, it's highly unlikely that someone would install a physical device in your house to MitM you.
    – FreeMan
    May 12, 2020 at 12:02
  • 3
    ...That said, understanding how to resolve the issue is good from an academic perspective.
    – FreeMan
    May 12, 2020 at 12:03
  • 3
    "...or other ingress points of your home (windows, etc.)" I see what you did there. :-P Anyway, this is a prime example of a great answer that both addresses the immediate problem of the OP (the plausibility analysis) and provides a reference for others who find this question in the future (verifying the fingerprint via another channel).
    – Heinzi
    May 12, 2020 at 12:26

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.

  • 3
    The OP asked “ I want to know what I should do to actually rule out (or confirm) an attack before fixing it.". I don't see anything answering that, you're only explaining why it may have changed, but that wasn't the question.
    – Calimo
    May 13, 2020 at 5:27
  • 3
    @Calimo But Occam's razor shaves away the conspiracy theory in the face of a simple, straight-forward explanation. Of course, Mr. Evil could have lurked in your network until you were finally done re-installing Linux on the Pi and then mounted his MiM attack exactly when you hit the enter key to connect for the first time, like Inidiana Jones did to avoid detection by the librarian. May 13, 2020 at 6:32
  • @Peter-ReinstateMonica that's no excuse to not answer the question.
    – Calimo
    May 13, 2020 at 6:37
  • @Calimo Sometimes people ask wrong questions because they aren't knowledgeable enough. I believe this is one of these cases. OP invested their time to understand what the message means and how to fix the problem, they clearly want to learn how to deal with it, but they don't know that it's not written with small local networks in mind, where a MitM attack would be very unlikely. So I tried to use OP's attention to educate them (so they know what caused this misleading message) instead of following an unlikely scenario of a MitM attack in LAN.
    – gronostaj
    May 13, 2020 at 7:08
  • 3
    @Calimo At a certain level it is. If, say, somebody asks "what's the best way to prevent top politicians from abusing children in a pizzeria" you do not dive into surveillance and weaponry details. This question here is, of course, not insane, but it is still rooted in a misconception which should be addressed. Joerg's answer addressed this very nicely (and there is no harm in discussing LAN proofing for posterity, as opposed to pizzeria proofing). May 13, 2020 at 8:34

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.

  • 5
    I'm not sure if this actually makes anything clearer. OP has apparently connected to this IP/hostname in the past. I'd assume this is the machine they normally used to log in.
    – gronostaj
    May 12, 2020 at 6:19
  • 1
    @gronostaj Not likely. If this was the machine he normally uses to connect to it, he wouldn't get that message. And he likely at least set it up initially using a console. May 12, 2020 at 17:22
  • 4
    He would get this message after reimaging the Pi.
    – gronostaj
    May 12, 2020 at 18:08
  • "Log into the Raspberry Pi from the machine you normally log into it with" quite obviously the OP can't log in due to the warning they describe. This answer would be more useful if you described alternative ways to log in.
    – Calimo
    May 13, 2020 at 6:44
  • 1
    "from the machine you normally log into it with" implies remotely or perhaps via serial console... it certainly doesn't imply "use the console"., especially not if they don't typically do so.
    – Attie
    May 13, 2020 at 22:23

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.


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.


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.

  • 2
    You actually don't need root because ssh-keygen -l prints the same fingerprint for the public and private part of a keypair (and the public keys are world-readable); you can just run ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub
    – josh3736
    May 13, 2020 at 0:16
  • In fact, wouldn't it be pretty odd if just trying to connect to a host leaked information about that host's private key? Wouldn't that, y'know, sort of defeat the purpose of said key being private? 🙂
    – Matthew
    May 13, 2020 at 19:30
  • Ah yes, you're right. I've updated the answer. Thanks! May 13, 2020 at 21:11

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 )


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 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 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 (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.


  • 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.


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .