How can I confirm that this SSH warning is not a genuine man in the middle attack? “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!”
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.
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.
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.