> I'm sitting here still trying to think of a way to prevent MITM attacks if you have no idea who the guy is on the other side... Maybe I need to drink more tea this early in the morning?
It's not that you don't know who the guy is, you just don't rely on a 3rd party to tell you that. See how SSH fingerprinting works.
SSH keys work exactly like self-signed certificates. On first connection you get the "whoah, this isn't trusted, do you want to proceed" warning, and if you accept, you are not warned in the future unless the key changes.
If browsers would make it easier to "permanently accept" a self-signed certificate (right now it's usually a multi-step process with blood-red warning messages at every step) we'd have the same situation as SSH keys.
HTTPS involves multiple servers that are interchanged regularly and commonly use different keys. The keys change regularly. There'd be no way to know if the key changing is part of regular operation or a man in the middle.
It would be unwise to do so. In any case, phasing out old servers and certs for new ones is common practice. Using one cert everywhere (which would mean using one set of keys everywhere, which is a horrible idea) would require more downtime for maintenance of the certificates. It's not gonna happen.
It doesn't, as a MITM prevention technique, for a gullible population. It doesn't even work for non-gullible population that's been trained to always hit "Y" on first connection from a host to a new server... err... I mean first connection to a MITM who then talks to the new server for you.
There are ways to make the situation slightly harder like the extremely unpopular idea of putting SSH host keys in DNS and then securing DNS ... err .. probably securing DNS via a CA type backend.... Well even unsecured DNS holding SSH host keys is better than nothing, or at least it makes people more susceptible because they feel safer, or something like that.
The odds of encountering a MITM attack on your first connection to a new server are low.
If it does happen, then the attacker will have to keep doing it forever, or else you'll get a warning the moment you manage to connect directly to the site without the MITM.
If your first connection is direct, then you're safe from MITM forever. If your first connection is compromised, then at least you'll likely discover that fact quickly.
ssh only gives you the "y/n" choice the first time you connect. If you've connected before but the key has changed, it throws up a very nasty warning and does not even give you the choice to continue. You have to manually edit your key file to remove the offending entry if you want to start using the new key.
It's not that you don't know who the guy is, you just don't rely on a 3rd party to tell you that. See how SSH fingerprinting works.