Not a joke. I'm suspecting you don't understand that this is using a kernel-level feature, so if you think the joke is MD5, then please add rfc5925 to every OS so that I can switch to a better algorithm.
You use what actually exists. It's orders of magnitude better than portknocking BS.
Deploying a half-assed encrypted transport in front of a full-assed encrypted transport because you're afraid you might not know how to configure the full-assed encrypted transport is pretty funny, which is why I thought it might be a joke.
Port knocking, fail2ban, nonstandard SSH ports, all of that stuff is theater.
Well, sorta. TCP MD5 hasn't had preauth exploits. OpenSSH has.
But also, like I said in my blog post (https://blog.habets.se/2019/11/TCP-MD5.html) this isn't just about targeted attacks, but this also hides from things like Shodan, which connects to all your ports and records your headers.
It helps with wide-scale scanning and wide exploitation. Security isn't a yes/no, and getting out these databases without restricting by IP address isn't without actual security value.
E.g. if you do this then next time there's an OpenSSH bug, you won't be in Shodan and other more secret scanning databases to be picked off right away.
Port knocking is just plain overengineered silliness. If plaintext password to unlock another port is what you want, set up a UDP server. "Connecting to random ports" is just fooling yourself about what you're doing.
TCP MD5 least has the benefit that it prevents any kind of shenanigans happening to your connection.
fail2ban, agreed. The value fail2ban adds is keeping your logs more quiet.
nonstandard SSH ports, agreed. Especially after everyone and their dog scans all ports on the whole internet now anyway.
How long ago was the last viable standard-configuration OpenSSH pre-auth vulnerability? Was it within the last decade? If it's the Debian RNG vulnerability --- a platform vulnerability, not an OpenSSH vulnerability --- how much further back do you have to go to find the next one?
Sure, it was a while ago. But there are less severe bugs too. Fact remains though that something more complex is more likely to have a bug.
With TCP MD5 you don't even have to consider SYNfloods or SYNcookies. And because only people with the MD5 secret can even connect, it becomes an early tripwire if someone does have the password. Currently if you have an OpenSSH open to the world you should expect your logs to be spamming 24/7, which makes smarter attacks not stick out.
Frankly, given the option I would prefer to not even have port 22 advertise to the world exactly which OpenSSH and OS I use. Not because of security through obscurity, but just to make it slightly harder, and thus harder to get in without tripping any of the tripwires.
Then there's also people who add 6 digit OTP as a second factor. Those are pretty brute-forcable by default, so you can actually do online brute force of a user's password still. Just slower. (OpenSSH has a ratelimit, but I've gotten around TOTP this way). With a system wide good secret this can prevent brute forcing even in the presence of bad user passwords.
But if you've already decided that security is either yes or no, and that OpenSSH is marked "yes secure, and therefore can be open to the world forever, bravely taunting any attacker saying 'this far, no further'", then there's nothing I can say to convince you.
But also not everything on the Internet is (Open)SSH.
Oh, another aspect to this: OpenSSH may not have a bug, but maybe you need to interface using a PAM module to a radius or LDAP server. Suddenly the trust weakens.
You use what actually exists. It's orders of magnitude better than portknocking BS.