Remote host identification is different on different networks

Question

When I ssh to a server - let's call it x.x.x.x - over one network, Network A, I get a message that the remote host identification has changed.

If I use one of two other networks - call them Network B and Network C - to connect to x.x.x.x, I don't get the message.

That is, for the same IP address of x.x.x.x, Network A is giving back a different remote host identification than Network B and Network C.

So my theory is that since Network B and Network C agree, they are correct, and Network A must be giving me the wrong key somehow.

Network A gives the same results over Wi-Fi or ethernet. Network B is my home Wi-Fi and Network C is a mobile hotspot Wi-Fi.

I've rebooted Network A's router, but the different remote host identification persists.

Does this indicate a MITM attack? Is there anything else it could be? What are the next steps?

And to be clear, the problem is not just that it has updated. If I switch my known_hosts to contain the key that network A expects, it works, but then network B and C don't work, and vice versa. That is, they are currently expecting different keys.

Answer 1

The wrong key certainly implies that the encryption is being terminated somewhere other than at the intended host. That might be a mitm attack, it might be a redirection attack or it may be that the network you are connected implements some sophisticated technology for monitoring activity. But recognising a server host in SSH is solely based on the first time you connect to that host - hence it is also possible that network A is giving you an uninterrupted connection while B and C are the compromised connection although less probable than the original hypothesis.

A further possibility is that you are connecting to an SSH service implemented on more than one host. Although all the best practice I have come across (Redhat, VMware, SSH software corp, AWS) recommends using the same server key across all hosts implementing the service, when I was recently implementing such an infrastructure, the architect and security consultant insisted that the instances had to use unique keys (because that's what it says in the CIS checklist).

But the short version is this : we can't tell what is the true connection.

If you login with a password, you could be exposing this to an intended recipient. But if you authenticate using a key pair then an interloper cannot compromise your access.

As to the question of which key is the true key, if you can login using a key pair, and can verify that the host is the one you intended (e.g. your files are in your home dir) then try to SSH localhost and see what key is presented.