No, it's not. The article itself is somewhat incoherent; for instance, if you're using key-only authentication (which: of course you are) fail2ban has literally no function (unless you think attackers are brute-forcing ECDH keys).

The reality is that there are basically two ways to operate SSH:

(1) You can, because OpenSSH is the significant remote service with the literal best track record of any remote service, just disable passwords and let SSH run in 22/tcp exposed to the Internet. Probably stop logging people scanning you; there's nothing you're going to do about it, so it's not real information.

(2) You can keep SSH behind WireGuard, an even simpler security protocol with an even better security story (though: OpenSSH is quite solid), which is designed to not to chat with counterparties that don't have keys, even to do negotiation.

Everything else is performative.

I'd incline towards option (2).

OpenSSH has the best track record, but even it had a zero-day RCE (regreSSHion) in 2024.

There are bound to be many more discovered as LLMs capable of doing so proliferate among those who don't report such things responsibly.

Keeping port 22 open puts you first in line for such exploits, while keeping it behind another layer (whether it's WireGuard or firewall tricks) would buy time, if not keep attackers away entirely. That seems useful, no?

Fail2ban, port knocking, magic packets, setting custom port are basically toys for wasting time. There are always people who have their website hosted on a VPS arguing back and forth about setting custom port ... yeah good luck setting those toys when you have dozens of servers and more than 4 administrators and actual work to be done.

SSH with key-key only or WireGuard/VPN on top are exactly what everyone uses for daily driving.

Note that fail2ban is built inside OpenSSH, these days.

> if you're using key-only authentication (which: of course you are) fail2ban has literally no function (unless you think attackers are brute-forcing ECDH keys).

Why, fail2ban here still serve a very useful function: it bans the offending IP from talking to the machine. It's a simple and a very effective heuristic to block both non-offending port-scans and offending too.

> basically two ways

It's always amusing what people like you almost demand what ssh should be run on the port 22 but are fine with a random port for WireGuard.

And for all of you to assume what both 22/tcp and WireGuard are always available and never blocked.