[Jedd]

> Fail2Ban is useless on a properly configured SSH server (no root, no passwords, no kerberos, only keys).

This assertion confuses me.

I use fail2ban on boxes I have key-only ssh configured for.

Are you aware fail2ban works for services other than ssh?

If an attacker / script knocks unsuccessfully on my ssh door, other doors are then closed to them.

I also get much (much!) cleaner logs thanks to fail2ban.

[nixos]

>This assertion confuses me.

I suspect that you're confusing fail2ban and port-knocking (or using fail2ban as a port-knocker).

The point of fail2ban is to prevent an attacker from brute-forcing your server. In a key-only config, the chances of getting brute forced is smaller (by a few orders of magnitude) than getting hit by an asteroid and having the server get hit by an asteroid, so fail2ban doesn't really help.

_In theory_, the same would be true for port-knocking.

However, in practice, sshd can have security holes which a malicious scanner could exploit. And while port-knocking doesn't help against a determined attacker (it's subject to MITM, replay-attacks), it does help with defense-in-depth.

[timtadh]

That is true and a good use case for fail2ban. Useless was probably a strong word, what I really meant was of limited utility in increasing the security of the SSH service.

[tytso]

The main reason I use fail2ban is I got tired of the log file noise/bloat. I use key-only access on my servers already, with the key stored on a hardware token (Yubikey).

[problems]

I guess the question then is why you're looking at failed Auth logs. Failed auths are boring, doubly so on a key only server. Successful auths are where the fun is at.

[pm215]

When I first set up fail2ban it was because I got annoyed that the machine on my desk was making regular "clunk...clunk...clunk" noises from the hard disk as it wrote another failed-auth attempt to the log every second or so...