> Adding an additional dependency (of say a port-knocking library) doesn't look great in that regard, if the dependency can be hijacked to add remote code execu

> Adding an additional dependency (of say a port-knocking library) doesn't look great in that regard, if the dependency can be hijacked to add remote code execution capabilities. 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-configure-port-knocking-using-only-iptables-on-an-ubuntu-vps 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).