Linux · medium · Access, hardening & packages

fail2ban is not banning, or has banned you

The jail is not reading the right log, the filter does not match the log format, or your own address has been caught.

What you see

Repeated failed logins continue with no bans, or a legitimate address can no longer connect and the ban list explains why.

What is actually wrong

On systemd systems the authentication log is in the journal rather than a file, so a jail configured for a path finds nothing. Filters also drift out of step with log format changes.

Codes and articles

fail2banFound no accessible config filesjail sshdBan 192.168Failed to execute ban jail

Fixes (2)

Unban an address and keep it out of range

Root shell, via console if locked out15 minuteslow riskreversible

A legitimate address has been banned.

See the jails and their current bans.

Shell

sudo fail2ban-client statussudo fail2ban-client status sshd

Unban the address.

Shell

sudo fail2ban-client set sshd unbanip 203.0.113.5

Add the office or management range to the ignore list so it cannot recur.
Shell
```
sudo tee -a /etc/fail2ban/jail.local >/dev/null <<'EOF'[DEFAULT]ignoreip = 127.0.0.1/8 ::1 203.0.113.0/24 10.0.0.0/8EOFsudo systemctl restart fail2ban
```
An ignore list containing the addresses you administer from is the difference between fail2ban protecting the machine and fail2ban locking you out of it at the worst moment.
Keep an out-of-band route — a hypervisor console or a second port that fail2ban does not watch.

Confirm it workedThe address connects and is listed in ignoreip.

Shell

sudo fail2ban-client get sshd ignoreip

If you need to undo itRemove the ignoreip line and restart to return to the previous behaviour.

Point the jail at the right log and filter

Root shell30 minutesmedium riskreversible

Nothing is being banned despite obvious attempts.

Check the service is running and the jail is enabled.

Shell

systemctl status fail2ban --no-pagersudo fail2ban-client status

Check the backend. On a systemd system with no /var/log/auth.log, a jail using the file backend reads nothing and reports no error.
Shell
```
grep -rE '^\s*backend|^\s*logpath' /etc/fail2ban/jail.local /etc/fail2ban/jail.d/ 2>/dev/nullls -l /var/log/auth.log /var/log/secure 2>/dev/null
```
This is the most common cause on current distributions. The jail is enabled, the service is healthy, the filter is correct, and it is watching a file that does not exist.

Set the systemd backend where appropriate.

Shell

sudo tee /etc/fail2ban/jail.d/sshd.local >/dev/null <<'EOF'[sshd]enabled = truebackend = systemdmaxretry = 5findtime = 10mbantime = 1hEOFsudo systemctl restart fail2ban

Test the filter against real log lines rather than waiting to see if it works.
Shell
```
sudo fail2ban-regex systemd-journal /etc/fail2ban/filter.d/sshd.conf
```
fail2ban-regex prints how many lines matched. Zero matches with plenty of failures in the log means the filter, not the configuration — and it takes one command to know which.
Check the ban action can actually run — a mismatch between the configured action and the firewall in use fails silently.
Shell
```
sudo fail2ban-client get sshd actionssudo nft list ruleset | grep -i f2b
```

Confirm it workedfail2ban-regex matches real entries and a test failure produces a ban.

Shell

sudo fail2ban-client status sshd

If you need to undo itRemove the jail.d file and restart to return to the shipped defaults.

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.