Hacker News Reader

Comment by vbezhenar | Hacker News Reader

ssh is terribly insecure with no way of checking server certificate fingerprint automatically. Web solved it decades ago with CA.

View on HN

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.

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).

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?

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.

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.

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 :-).

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.

OpenSSH supports DNSSEC-published host key fingerprints.

Leaving off everything else I think about DNSSEC, this is a baffling feature. DNS solves the problem of introducing unrelated counterparties, which is not the SSH host key problem --- people generally don't SSH into hosts they're not somehow affiliated with. This is what CA-based PKIs are made for, and OpenSSH has a good (non-X.509) certificate system already; lots of people use it to get e.g. SSO login for SSH.

Tying authenticity to a global, remote set of authorities is a tradeoff we make for anonymous introductions to random web servers whenever we need them. SSH doesn't have that problem, so the tradeoff gets you... nothing?

> people generally don't SSH into hosts they're not somehow affiliated with

git remote add ... git+ssh://user@github.com/... comes to mind as a counterexample, although I admit there aren't many of these examples and GitHub also supports authenticated https:// with git. GitHub don't publish SSHFP DNS records either it seems, but the feature is there in the client.

Reply on news.ycombinator.com