Configure Fail2ban to Protect SSH on Linux

Fail2ban watches authentication failures and adds a temporary firewall block when one IP crosses your threshold. For SSH, enable the sshd jail when you want repeated failed login attempts to trigger temporary source-IP blocks — after basic OpenSSH hardening.

The walkthrough uses short lab values (bantime = 2m, findtime = 1m, maxretry = 3) so the ban is easy to verify. Choose production values according to your login pattern and lockout policy.

Quick answer

After install on any distro, run sudo fail2ban-client status sshd and note whether the jail reports Journal matches or a File list — that tells you which backend is active on your host.

How Fail2ban protects SSH

Fail2ban runs fail2ban-server as a daemon. It applies filter rules to log lines (or journal entries) that match failed SSH authentication, counts failures per source IP inside findtime, and calls a ban action when maxretry is reached.

On a typical setup:

• The filter reads sshd failure messages (Invalid user, Failed password, and similar).
• The action inserts a firewall rule that drops or rejects traffic from the offender for bantime.
• When bantime expires, Fail2ban removes the rule automatically.

Fail2ban complements — it does not replace — disabling password auth, using keys, and limiting PermitRootLogin.

Install Fail2ban

RHEL, Rocky Linux, AlmaLinux, and Fedora

Fail2ban ships in EPEL on RHEL-family systems. Install the repository, then the package:

sudo dnf install epel-release fail2ban -y

On RHEL 10 the search shows the expected package name:

======================== Name Exactly Matched: fail2ban ========================
fail2ban.noarch : Daemon to ban hosts that cause multiple authentication errors

The fail2ban-firewalld subpackage is pulled in on hosts that use firewalld. It sets firewallcmd-rich-rules as the default ban action.

Confirm the version you installed:

rpm -q fail2ban-server

Sample output:

fail2ban-server-1.1.0-6.el10_0.noarch

Debian and Ubuntu

On Debian-family systems Fail2ban is in the main archive:

sudo apt update
sudo apt install fail2ban -y

In a Debian 12 container used for this refresh, the installed versions were:

fail2ban 1.0.2-2
openssh-server 1:9.2p1-2+deb12u10

Start Fail2ban and run sudo fail2ban-client status sshd. If the jail reports a File list pointing at /var/log/auth.log but that file does not exist, install and start rsyslog so authentication events are written there:

sudo apt install rsyslog -y
sudo systemctl enable --now rsyslog

If the status output shows Journal matches instead, the jail reads the systemd journal and you do not need auth.log for SSH monitoring on that host.

Enable the sshd jail

Shipped defaults keep jails disabled until you opt in. Add a drop-in under jail.d instead of editing jail.conf (package updates can overwrite the main file).

Create /etc/fail2ban/jail.d/00-sshd.local with short lab values you can replace for production:

sudo tee /etc/fail2ban/jail.d/00-sshd.local <<'EOF'
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1
bantime  = 2m
findtime = 1m
maxretry = 3

[sshd]
enabled = true
EOF

The settings mean:

• ignoreip — never ban these addresses (add your admin VPN or office subnet in production).
• findtime — window in which failures are counted together.
• maxretry — failures inside findtime that trigger a ban.
• bantime — how long the firewall block lasts.

Add trusted admin networks to ignoreip before you test with deliberate failed logins. Locking yourself out of SSH is a common first-time mistake.

Start Fail2ban and verify the jail

Enable and start the service:

sudo systemctl enable --now fail2ban

Check that the unit is running:

systemctl is-active fail2ban

Sample output:

active

List active jails — you should see sshd:

sudo fail2ban-client status

Sample output from the RHEL lab:

Status
|- Number of jail:	1
`- Jail list:	sshd

Inspect the jail backend and ban counters:

sudo fail2ban-client status sshd

On RHEL 10 the jail reads the journal and uses the firewalld action:

Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- Journal matches:	_SYSTEMD_UNIT=sshd.service + _COMM=sshd + _COMM=sshd-session
`- Actions
   |- Currently banned:	0
   |- Total banned:	0
   `- Banned IP list:	
The jail sshd has the following actions:
firewallcmd-rich-rules

In the Debian 12 container lab — after rsyslog was added — the same command showed File list: /var/log/auth.log and iptables-multiport as the ban action. On your host, trust the status sshd output rather than assuming either backend or action.

Test the ban with failed SSH logins

Run failed attempts from a second host (not from the server console logged in as root on the same IP Fail2ban sees as ignoreself). From vm2.lab.example three invalid-user tries against vm1.lab.example produced:

for i in 1 2 3; do
  ssh -o BatchMode=yes -o StrictHostKeyChecking=no bogus@192.168.56.116 exit
  sleep 1
done

Each attempt returned Permission denied until the fourth try hit the ban:

bogus@192.168.56.116: Permission denied (publickey,password).
bogus@192.168.56.116: Permission denied (publickey,password).
bogus@192.168.56.116: Permission denied (publickey,password).
ssh: connect to host 192.168.56.116 port 22: Connection refused

After the threshold, the jail reported the client source address (192.168.56.156 from vm2):

sudo fail2ban-client status sshd

Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	3
|  `- Journal matches:	_SYSTEMD_UNIT=sshd.service + _COMM=sshd + _COMM=sshd-session
`- Actions
   |- Currently banned:	1
   |- Total banned:	1
   `- Banned IP list:	192.168.56.156

On RHEL with firewalld, list rich rules to see the reject rule Fail2ban added:

sudo firewall-cmd --list-rich-rules

Sample output:

rule family="ipv4" source address="192.168.56.156" port port="ssh" protocol="tcp" reject type="icmp-port-unreachable"

The Debian 12 container test through published port 2222 banned the container gateway address 10.88.0.1 after the same three-failure pattern — confirming a file-based jail works outside the RHEL journal path used above.

Unban an address and tune ignoreip

When you lock out a lab client, remove the ban immediately:

sudo fail2ban-client set sshd unbanip 192.168.56.156

Sample output:

1

Recheck the jail — the banned list should be empty:

sudo fail2ban-client status sshd

The Banned IP list line should show no addresses. To prevent future bans for a subnet, add it to ignoreip in 00-sshd.local and reload:

sudo fail2ban-client reload sshd

You can also add a single address at runtime (lost on service restart unless it is in the file):

sudo fail2ban-client set sshd addignoreip 192.168.56.0/24

Where the sshd jail reads failures

Do not assume one path from the distro name alone. After you start Fail2ban, run:

sudo fail2ban-client status sshd

If the filter section shows Journal matches, the jail reads sshd events from the journal (typical on RHEL 10 in this lab). If it shows File list: /var/log/auth.log, the jail tails that file — which is what the Debian 12 container used once rsyslog was running.

If Total failed never increments, check the backend your status output reports first, then rule out testing from an address in ignoreip or matched by ignoreself, or too few failures inside findtime.

Useful fail2ban-client commands

Runtime banip / unbanip changes apply immediately; persistent settings belong in /etc/fail2ban/jail.d/*.local.

Troubleshooting

References

• fail2ban(1)
• fail2ban jail.conf manual
• firewalld.richlanguage(5)
• Debian Fail2ban wiki

Summary

Fail2ban gives you an automatic SSH safety net: enable the sshd jail in /etc/fail2ban/jail.d/00-sshd.local, set ignoreip for networks you never want blocked, and tune bantime, findtime, and maxretry to match your lockout policy.

On RHEL-family servers the jail commonly reads sshd events from the systemd journal and, with fail2ban-firewalld installed, adds firewalld rich rules. On Debian and Ubuntu the backend may be the journal or /var/log/auth.log depending on package defaults — use fail2ban-client status sshd to see Journal matches or File list on your system. In the tested Debian 12 package the ban action was iptables-multiport; other releases or local configs may differ. Test bans from a remote client so ignoreself does not hide your failures, and keep fail2ban-client set sshd unbanip handy during the first rollout.

After a successful lab test, adjust thresholds for production and add your admin sources to ignoreip before you rely on the jail on production SSH. Pair Fail2ban with key-based login and the broader checklist in prevent brute force SSH attacks rather than treating it as the only control.