[karmarepellent]

This is incorrect. SSH certificates work just like x509 certificates in that regard. Also, with PubkeyAuthentication, there exist all kinds of ways to collect host keys before connecting to them for the first time and thus avoiding the trust-on-first-use problem. Especially in private networks where you control all the nodes.

[palata]

SSH does have certificates, but in practice most people using SSH don't use SSH certificates and don't check the fingerprints.

Not sure if we can say it's solved if nobody wants to use it by choice (certificates are probably mostly used in enterprise setups, but in my experience it's not even that common there).

[tptacek]

If you have a small, stable number of hosts, an SSH PKI doesn't make a lot of sense. With a large fleet, and/or if you want to tie your fleet into an OIDC IdP, certificates are pretty common; the most common way of solving this problem, I think?

[palata]

I think it's the case in big companies. But most companies are not big :-), which means that a lot of people are using SSH without ever checking the fingerprint. That would be my intuition.

[tptacek]

SSH has always relied on key continuity for this problem; you're exposed when you're first introduced to a host (on a particular client) but then fine from that point on.

This of course breaks down with cattle fleets where ~most logins are to hosts you've never hit before, which is why cattle fleets tend to use SSH PKI.

[palata]

Over the years I have seen - repeatedly - colleagues just removing ~/.ssh/known_hosts when SSH showed the warning that says something like "YOU MAY HAVE BEEN HACKED!!!".

I think passkeys resolve that, even though it's more of a human issue than a technical issue :-).

[vbezhenar]

When I connect to github using ssh, I must google github page with ssh fingerprint and verify it by hand. Imagine how many people actually do that, instead of blindly accepting the key.

If github can't make it right, nobody can.