Set up Fail2Ban for SSH

The fix/etc/fail2ban/jail.local

[sshd]
enabled  = true
backend  = systemd
maxretry = 4
findtime = 10m
bantime  = 1h
ignoreip = 127.0.0.1/8 ::1 203.0.113.10

sudo systemctl enable --now fail2ban
sudo systemctl restart fail2ban

Put your own administrative address in ignoreip.

Be clear about what this buys you

Fail2Ban is the most over-recommended item on most SSH hardening lists, and it’s worth being honest about where it sits.

If you still allow password authentication, Fail2Ban is a genuine control. It turns an unlimited guessing budget into a few attempts per hour, which is the difference between a feasible and an infeasible attack.

If you have already required key-only authentication — which you should have, and which is listed above this one for that reason — there is no password to guess. An attacker making a million attempts against a key-only daemon gets a million rejections. Fail2Ban then buys you:

• Much quieter logs. This is the real benefit, and it isn’t trivial: a genuine anomaly is easy to miss in a wall of scan noise.
• Slightly less wasted CPU and fewer open connections from scanners.
• Not meaningfully less risk of compromise. The door was already locked.

That’s why this is low severity and near the bottom of the list. It’s worthwhile housekeeping, not a control that closes an exposure. Apply it after the ones that do.

The backend catches people out

The sshd jail defaults to reading a log file. On systems that log only to the systemd journal — which includes recent Debian and RHEL family releases — /var/log/auth.log may not exist, and the jail silently matches nothing. It appears enabled and bans nobody.

Setting backend = systemd reads the journal directly and sidesteps the whole question. If you prefer file-based matching, confirm the file actually exists and is being written first:

sudo ls -l /var/log/auth.log /var/log/secure 2>/dev/null

Verify it worked

Confirm the jail is not just enabled but actually matching:

sudo fail2ban-client status sshd

The output shows both totals — this is the important part:

|- Filter
|  |- Currently failed: 0
|  `- Total failed:     37
`- Actions
   |- Currently banned: 1
   `- Total banned:     4

Total failed: 0 on an internet-facing host that has been up for a while is the failure signal, not a success one. It means the filter is reading nothing — almost always the backend problem above.

Check the ban actually reached the firewall:

sudo iptables -S -t filter | grep -i f2b   # or: sudo nft list ruleset | grep -i f2b

Before you apply this

Fail2Ban can ban you. Fat-finger your own password or key a few times from the office and your address is dropped for bantime.

Put your administrative address in ignoreip before enabling the jail. If you are already locked out and have another route in:

sudo fail2ban-client set sshd unbanip 203.0.113.10

Beware bantime = -1 (permanent) combined with a dynamic home address: you can ban an address that later belongs to someone else, and accumulate a ban list that never expires. An hour is enough to defeat automated guessing.

Related

• Require key-only SSH authentication — do this first; it’s what makes this page optional.
• Firewall the SSH port — closes the exposure instead of rate-limiting it.