With SSH, if you care, you just need to check the fingerprints. With HTTPS, you have to implement certificate pinning (or set up a private CA and configure everything to ignore the system roots of trust), which is much more onerous.
Thanks for helping to improve https, since it helps in practice.
edit: Another way to put it is that if you want to reduce your attack surface to just the client and server machine, it's easy enough to scale SSH fingerprint verification to a few dozen machines. It's much, much harder to get SSL to provide that property for even two machines.
As for scaling to 100's of machines, it's not obvious to me that bootstrapping and rsyncing a known_hosts file and /etc/ssh_config that turns off trust on first use is harder than setting up a CA.
For millions of machines, SSH falls over (because known_hosts would be too big), but at that point, you're talking about what percentage of machines are compromised in steady state, not how to keep all attackers out. That's where HTTPS works well.
Thanks for helping to improve https, since it helps in practice.
edit: Another way to put it is that if you want to reduce your attack surface to just the client and server machine, it's easy enough to scale SSH fingerprint verification to a few dozen machines. It's much, much harder to get SSL to provide that property for even two machines.
As for scaling to 100's of machines, it's not obvious to me that bootstrapping and rsyncing a known_hosts file and /etc/ssh_config that turns off trust on first use is harder than setting up a CA.
For millions of machines, SSH falls over (because known_hosts would be too big), but at that point, you're talking about what percentage of machines are compromised in steady state, not how to keep all attackers out. That's where HTTPS works well.