> Is there any point in Fail2Ban if you're using keys and have disabled passwords?
I’d say no. Back in the mid 2000s, I used to use Fail2Ban as an extra layer of defense but users on Stack Exchange and Hacker News (like tptacek¹) convinced me that it was pointless if I’d already disabled password authentication.
To minimise noise in my logs and to have an extra layer of defense, I only allow TCP access to Port 22 (with rate-limiting) from my home ISP’s network block, my work IP address and via the Wireguard network interface (in case my home or work ISP change the IP addresses they provide to customers).
I have considered using Fail2Ban to stop spammers using too much Postfix resources but so far I’ve got away with postscreen and configuring Postfix to reject spam attempts as early as possible during the SMTP transaction. Similarly, my Apache server gets hammered with exploit attempts but I haven’t got around to investigating how useful Fail2Ban would be for minimising how much server resources are used in responding to these malicious HTTP requests.
I move SSH to a different port... I know it's easy enough to discover through a port scan, but it cuts a LOT of noise down. For home, I only allow the wireguard port from the outside.
I tend to start with Ubuntu Server these days as the SSH config is pretty much where I want in the box and will import my public key during setup. I also now use Caddy for reverse-proxy duties over Nginx.
Fail2Ban doesn't do much for SSH other than keeping your logs cleaner if you're using key based auth. It's quite good for protecting other services like Vaultwarden for example. Of course, it's just one additional layer. The important part is to configure the services themselves to be more secure.
