For SSH, changing to a random port number resulted in zero connection attempts from bots for months on end. It seems bots just never bother scanning the full 65535 port range.
For most of my VMs there's no ssh running. I use wireguard to connect to a private IP. I haven't done this on the bare metal yet but I might. Though barring exploits like we had recently nobody is getting into a server with either strong passwords or certificates. Fail2ban in my eyes is a log cleaner. It's not useful for much else.
A server with fail2ban can be DOSed by sending traffic with spoofed IP addresses, making it unavailable to the spoofed IP addresses (which could be your IP, or the IP of legitimate users).
That is typically a bigger problem than polluting your logs with failed login attempts.
Yeah, but many ISPs, especially smaller, have a same pool of ip addresses for all of their users in that 'region' (for whatever size and definition of a "region").
So with some effort, reconnections from/to a mobile network and many tcp/ip connectons, you can achieve that your device is connecting to the attacked site with many different (if not all) IP addresses from the ISPs pool, and if each of those is blocked, none of the legit users (using the same IP address pool) can access those services anymore.
Look at services like digitalocen with cheap virtual machines... even amazon... so many of their IP addresses were used for something "bad" and got blocked, that running a legit service on any of them can mean that a portion of your potential users won't be able to access them, because they'll be on some block list somewhere.
Don't most isps check the source address before relaying traffic nowadays? I know at least one of mine started a few years ago (and we had no idea we were asymmetrically routing our traffic till then...)
fail2ban is another layer which is susceptible to abuse and vulnerabilities. It might keep noise out of your logs but at a huge cost. I'd rather just change the SSH port to something non-standard and write it down.