[watermelon0]

Unless you manage to leak your private host/client SSH keys, this is close to being as secure as it gets.

I'd say that HTTPS (or TLS in general) is more problematic, since you need to trust numerous root CAs in machine/browser store. Sure, you can use certificate pinning, but that has the same issues as SSH host key verification.

[0xbadcafebee]

CA compromise is very rare and difficult. There are much easier attacks on TLS than that (notably, attacking insecure validation methods; the problem isn't that CAs aren't secure, it's that validation methods and their dependencies are insecure). Besides, the CAs for TLS only covers transport security; authentication+authorization would be handled securely through OIDC, using temporary sessions and not exposing the true credential, often combined with 2FA. Even you successfully attack a TLS server, two factors, and an active session, it only works once; you have to keep pulling it off to remain inside.

Compare that to malware that just copies a developer's ssh private key off the disk (again, almost nobody ever password protects theirs). This just happened recently on a massive scale with the npm attacks. Or intercepts the first connection from a client host and, again, because nobody ever validates keys, injects a false host key, and now they're pwnd indefinitely. Or, again, companies that do not strictly validate host keys, meaning immediate MitM. There's like a dozen ways to compromise SSH. It doesn't have to be that way, but it is that way, because of how people use it.