Port knocking, and other bespoke middle layers in front of internet services, is stupid. It violates Kerckhoffs’s principle¹. If you want more secret bits which users need to know in order to access your system, increase your password lengths, or cryptographic key sizes. If you want to keep log sizes (or “noise”) manageable, adjust your logging levels.

Anything added in front of your normal service also complicates access, since it’s non-standard. If you want a standard solution to solve all your needs for secure access of IP-based services, use IPsec and be done with it once and for all.

1. <https://en.wikipedia.org/w/index.php?title=Kerckhoffs%27s_pr...>

(Adapted from this old post: <https://news.ycombinator.com/item?id=39898061>)

Agreed.

And for logging in particular: Just switch the logging over to a temp file that lives in RAM (what disk thrash/write-amplification/SSD wear?), or even disable it altogether for failed login attempts.

We already know that there are great hordes of zombies outside of the castle, banging on the doors and the blocked-off spaces where the windows once were, picking away tirelessly. That's been a constant for many years. Documenting their continued persistence is pretty meaningless. None of it is actionable, or stoppable. It's just going to keep happening. Recording attempts from valid users is also largely without merit; it also just looks like noise, and we've got other ways to troubleshoot stuff that breaks without maintaining a long list of zombie attacks to peruse.

If a zombie actually manages to get in, then that's pretty important to keep track of; log that. But the attempts don't mean anything and have not meant anything for a very long time.

(When the word comes forth that the zombies are gone and the noise has ceased, it will be broadcast so far and wide that even the most noise-deafened sysadmins will find it impossible to ignore. In that seemingly-impossible unlikelihood, we can then resume recording attempts to log in with ssh.)

I agree port knocking is a direct violation of Kerckhoff's principle. However, the proposed solution has non-discoverability from unauthorized sources which isn't necessarily in the threat model of OpenSSH or general cryptography. I do feel like this is potentially a desirable trait. I elaborated a bit more here[0], but I'm curious if you have any grander thoughts on how this could be approached

[0]: https://news.ycombinator.com/item?id=49307986

It violates Kerckhoffs’s principle¹

Appeal to authority?

In the real world, it doesn't matter. Anything that makes the attacker's life harder is fair game. Stupid dogmatic sheep-like mindlessness only leads to "herd exploitability".

also complicates access

That's the whole point.

No, it doesn't. You're arguing against a straw man. The primary motivation was in second paragraph.

It is not stupid. Your stated principle assumes the exposed OpenSSH server does not have pre-auth 0-days. Having open 22 exposes a lot of information about the machine already, not to mention possible banners. The mentioned method is an elegant solution to both risks.

I think you are missing the point. It isn't about increasing the bits of security, it's about avoiding the flood of port scanners and the logs that produces.

IPsec is way more complicated to set up than this (or other VPN solutions like Wireguard or OpenVPN for that matter), and doesn't even completely solve that problem, because your ipsec port is open. Although, admittedly, there are probably less bots looking for ipsec than ssh.