SSH host identification changes on one wireless network

Solution 1:

Either this systems host keys are changing or someone/something is MITM'ing the SSH connection.

The appropriate course of action is to consider that host as compromised (although its likely not the host itself, rather the connection) unless/until you have an explanation.

You may want to reach out to the system administrator of that AP and advise them of your concerns and try and track this down with them.

Solution 2:

Since it's an academic institution, I'm thinking it's probably a firewall/security gateway that intercepts and analyzes the SSH traffic for things like Data Loss Prevention (DLP) or general audit logging.

For example of such a firewall: https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/decryption/decryption-concepts/ssh-proxy.html

---

Solution 3:

The answer by davidgo is correct. Note that, as long as you're using pubkey auth and not password, this MITM does not compromise the safety of your credentials. But it does compromise the privacy and authenticity of anything transmitted over the session. Note that "authenticity of anything transmitted over the session" includes (rather, probably consists entirely of) commands sent to the shell or whatever process you're interacting with and output sent back.

I had originally suggested the following, which is dangerously wrong, at least without further measures:

One easy workaround is double-ssh. Assuming the host you're logging into allows port forwarding, login once with the compromised connection, using pubkey auth and with forwarding enabled to forward a local port to localhost:22, e.g. -L 12345:localhost:22. Now, you can run a second ssh session tunneled through the first, and unless the attacker is actively anticipating you doing this, this second session will have the right host fingerprint and you know that it's actually secure, not subject to interception by the MITM.

This was written hastily as a simplification from the right way I had in mind to do it, which is to have a separate login account used purely for forwarding, with no shell, which I believe is still safe to use with a compromised (MITM'd) connection, but I'd still advise caution. It may also be possible to setup your authorized_keys file to limit the key you use for the initial (MITM'd) login so that it's unable to issue any commands, only forward connections; if so, such a setup should be safe.