It means that people who can't intercept traffic can't talk to the ssh server-- and that's most attackers at the beginning phases of an attack. And even someone who can intercept traffic needs to wait for actual administrative activity.
Also underrated I think is security by simplicity. OpenSSH should be extremely simple and easy to understand, such that every proposal and change could be easily scrutinized. Cryptographic constructions themselves are almost mathematically proven invulnerable, then a small codebase can go most of the way to mathematically provable security (bonus points for formal verification).
But for this kind of system there's usually some kind of human vulnerability (e.g. system updates for your distro) in the loop such that the community needs to remain watchful. (It's fun to consider an application that's proven correct and doesn't need updating every again, but usually that's not practical)
Port knocking infrastructure can be minimal, knowing nothing but addresses knocking. It can also be completely outside the protected service on a gateway.
Indeed, it can even be no-code, e.g. https://www.digitalocean.com/community/tutorials/how-to-conf...
> OpenSSH should be extremely simple and easy to understand, such that every proposal and change could be easily scrutinized.
But OpenSSH intrinsically is going to have a much larger attack surface.
> then a small codebase can go most of the way to mathematically provable security (bonus points for formal verification).
It's worth noting this would not have helped against this attack:
* It was against another dependency, not openssh
* The actual vulnerability didn't occur in the code you'd inspect as part of verification processes today. (I don't think anyone is formally verifying build process).
Also, whenever some layers may allow compromising everything, the supply chains of the layers should be minimal or correlated (same supplier), to avoid increasing such supply chain risks.