how to install fail2ban on ubuntu 24.04

Wetin Fail2ban dey do

Fail2ban na daemon wey dey read log files. E dey watch your SSH authentication messages, and if one address fail many times inside short time, e go run firewall command wey go block that address for some time. Na that one be the main idea. E get about thirty lines of config inside one file, and for Ubuntu 24.04, you fit install am with one single apt command wey go protect you even before you edit anything.

Make you understand wetin e be and wetin e no be. Fail2ban no dey authenticate anybody, e no dey encrypt anything, and e no dey stop single login attempt wey person really plan well — e only dey stop repeated attempts from the same source. E be like noise filter and rate limiter, e no be lock. E job na to make sure say constant scanning for port 22 no dey waste your CPU, your bandwidth, and your log space, and to slow down any attacker wey must come from one address at a time.

Wetin Fail2ban no fit replace

Fail2ban na third layer, e no be first layer. If your server still dey accept SSH passwords, botnet wey spread across thousands of addresses fit continue to guess, because each address go dey under your ban threshold and e no go ever trip am. Real defence against that one na key-only authentication, wey make password guessing impossible no matter how many attempts person make. Fail2ban wey dey top key-only auth dey do two useful things: e dey trim the brute-force noise out of your logs, and e dey kick scanners out early so dem no go continue to hammer the port. Treat am as defence in depth. E dey sit behind key authentication and behind a firewall, e no dey ever sit for front of dem.

Prerequisites, and the Ubuntu 24.04 reality

You need VPS wey dey run Ubuntu 24.04 with root or sudo access, and SSH must dey work — e go beta if you dey use key authentication. Fail2ban no dey chop much: e only dey use few tens of megabytes of RAM, and you no need to tune any limits.

Now, dis part na wetin many old guide dey fail: For many years, dem dey tell people say "install Fail2ban, then add backend = systemd, because Ubuntu stop to write /var/log/auth.log." Dat advice na true because modern server and cloud images no dey carry rsyslog, so SSH logs only to de systemd journal and dat text file don vanish — but for Ubuntu 24.04, de Fail2ban package don already fix dat one. De package dey come with /etc/fail2ban/jail.d/defaults-debian.conf, and na dat file, no be de upstream defaults, wey your server dey use:

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]
backend = systemd

[sshd]
enabled = true

Read dis one well-well, because e go answer two questions before you touch anything. backend = systemd means de SSH jail dey read de journal, so de missing auth.log no matter at all. banaction = nftables means dem dey use nftables for bans, wey na de firewall Ubuntu 24.04 dey use now, instead of de old iptables. And [sshd] enabled = true means de jail dey work from de first boot. De result: stock apt install fail2ban for Ubuntu 24.04 dey ban SSH brute-force out of de box. Most of your work na to confirm dat, tune de policy, and make sure say you no lock yourself out.

De old auth.log trap still dey catch people for three situations, and e good to know dem: you install Fail2ban with pip instead of apt, so no defaults-debian.conf dey; you dey inside unprivileged container wey no get systemd journal to read; or you follow old tutorial and paste backend = auto inside your own jail.local, wey go override de working default. De failure-modes section go show you exactly how each one dey look.

Step 1: Install and confirm it is already banning

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 dey carry Fail2ban 1.0.2, and the package go carry python3-systemd as hard dependency, so the journal backend get everything wey e need. The service go enable and start itself:

sudo systemctl status fail2ban

You want active (running). Then look at the jail wey dey do im work already:

sudo fail2ban-client status sshd

For any public VPS wey don open for internet for even few minutes, you go often see failures wey dem don count and addresses wey dem don ban — the internet dey scan port 22 continuously. Na that one be proof say the stock config dey work. From here, you dey refine am, you no dey build am from scratch.

Step 2: Edit jail.local, no edit jail.conf

Fail2ban keep original default settings for /etc/fail2ban/jail.conf. No edit that file. Any apt upgrade wey come with package fit replace am, and your changes go vanish without warning. Fail2ban dey read files for one order — jail.conf first, then everything for jail.d/, then jail.local — and the last value na him go work. .local file na yours, and package upgrades no dey touch am. Same rule dey apply for filters, where one *.local file go override the original filter.d/*.conf.

So, you go write small jail.local wey go override only the few settings wey you want, and leave both jail.conf and the original jail.d/defaults-debian.conf untouched so you fit use dem as reference.

Step 3: Write /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

Copy this inside, but change the address for the ignoreip line to your own public IP:

[DEFAULT]
# Ubuntu 24.04 already sets these two in jail.d/defaults-debian.conf.
# Pinning them here documents the dependency and survives if that
# file is ever removed or changed by an upgrade.
backend   = systemd
banaction = nftables

# Ban for one hour ...
bantime  = 1h
# ... if an address fails ...
maxretry = 5
# ... 5 times within 10 minutes.
findtime = 10m

# Never ban these. PUT YOUR OWN IP HERE.
ignoreip = 127.0.0.1/8 ::1 10.0.0.24

# Longer bans for repeat offenders: 1h, 2h, 4h ... up to a week.
bantime.increment = true
bantime.maxtime   = 1w

[sshd]
enabled = true

Every line get importance:

• bantime, findtime, maxretry na dem be the policy. The default bantime wey come with the software na only ten minutes; one hour na better floor. If one address fail five times inside ten minutes, dem go ban am. Real people dey mistype password once or twice; five failures inside ten minutes na script.
• ignoreip na your safety belt. Put the public address wey you dey use connect from here so Fail2ban no go ever lock you out of your own server. If your home connection dey change IP, na why you go prefer the VPN approach wey dey at the end, no be reason to skip this line.
• bantime.increment = true dey make every new ban longer than the one before — one hour, then two, then four — up to bantime.maxtime. Addresses wey dey come back repeatedly go dey lock out more and more.

Find the address wey you wan whitelist from the machine wey you dey use SSH from, no be from the server:

curl -s ifconfig.me

You fit generate a jail.local wey fit your ports and ban policy for here, then paste am inside the file:

Step 4: Restart and verify say e dey read the journal

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

-t dey run config test first. So, if you write typo for jail.local, e go show error here instead of to let the service die. Healthy jail status go look like dis:

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

Di number wey go prove say Fail2ban dey really read your logins na Total failed. If di number high pass zero, or e dey increase when you try fail login from another machine, e mean say e dey read di journal and you don finish. If di number still dey 0 no matter how many times you fail — and you sure say you no dey test from di address for ignoreip — go check di failure modes below.

Notice say di Journal matches line still dey name sshd.service. For Ubuntu, di SSH unit na ssh.service, but di filter wey dey come with am dey match _COMM=sshd too. OpenSSH for 24.04 dey log failures from process wey dem call sshd, so di match go work. Dat detail only matter if you dey use newer OpenSSH (9.8 or later, wey di per-connection worker na sshd-session); di failure modes cover dat case.

Step 5: Watch a real ban land, or force one to test

Real bans arrive on their own within minutes on any public VPS. To watch one, tail the log:

sudo tail -f /var/log/fail2ban.log

A ban looks like this:

2026-07-15 10:31:40,502 fail2ban.filter  [812]: INFO    [sshd] Found 10.0.0.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 10.0.0.66

To prove the machinery end to end without waiting, ban a documentation address by hand — never your own:

sudo fail2ban-client set sshd banip 10.0.0.66

It prints 1, and the address appears under Banned IP list in fail2ban-client status sshd. Now confirm the block really exists in the firewall. On Ubuntu 24.04 that is nftables, not iptables:

sudo nft list table inet f2b-table

You will see a set named addr-set-sshd holding 10.0.0.66, and a chain f2b-chain that rejects any source in that set. If fail2ban-client says an address is banned but nothing appears in nft list, your ban action does not match your firewall — see the nftables/iptables note in the failure modes.

Step 6: Unban yourself, and recover if you are locked out

If you ban address wey you no suppose ban — like your own — remove am:

sudo fail2ban-client set sshd unbanip 10.0.0.66

E go return 1 if e work well. To clear every ban for every jail:

sudo fail2ban-client unban --all

No rely on SSH session wey don open to save you: nftables ban go reject every packet from the banned address to port 22 — even established connections — so existing session go freeze as soon as ban land. If you ban yourself and you no get ignoreip entry, you go lock yourself out until ban expire — use your provider web console (VNC or serial) to recover, because e no dey pass through SSH, and either wait for bantime or run the unban command for there.

Step 7: Make bans persist and escalate

Fail2ban dey keep active bans inside small SQLite database for /var/lib/fail2ban/fail2ban.sqlite3. This way, if you restart service or reboot machine, bans no go vanish; dem go stay. The bantime.increment lines wey you don add before go make repeat offender get wahala more as dem dey repeat mistake — the ban time go double from one hour reach one week.

If you want "three strikes" policy for the whole system, Fail2ban get one recidive jail wey dey watch its own /var/log/fail2ban.log. This jail go give long bans to any address wey dem don ban many times across all jails. Since your [DEFAULT] dey use systemd backend now, you must pin this jail back to the log file wey e suppose read:

[recidive]
enabled  = true
backend  = auto
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

backend = auto with the explicit logpath go make recidive continue to read the plain fail2ban.log. Na for there the Ban lines wey e dey count dey show. If you use the systemd default wey you set globally, e go point am to the journal, and the lines no dey there.

Step 8: Pair am with key-only SSH, and even better, a VPN

Fail2ban work well only when you use key authentication. Create one drop-in file inside /etc/ssh/sshd_config.d/ — for example /etc/ssh/sshd_config.d/00-hardening.conf — and set:

PasswordAuthentication no
KbdInteractiveAuthentication no

Then run sudo systemctl restart ssh. When you turn off passwords, brute force attack no fit work at all; Fail2ban den go just dey help to reduce log noise and kick out scanners early. Even better way na to keep SSH off the public internet entirely: put SSH behind a self-hosted WireGuard VPN and block port 22 for firewall so e go only answer for inside the tunnel. Nobody fit brute-force one port wey dem no fit reach, and Fail2ban go just dey act as backstop instead of front line.

Fail2ban no be for SSH only. Any service wey dey log failed logins fit get one jail — like mail server, nginx site, or a self-hosted Vaultwarden password manager wey you no want leave open for credential stuffing. Once web app sit behind an nginx site with a Let's Encrypt certificate, point one Fail2ban filter for its access log just like how the SSH jail point for the journal.

Failure modes, with the exact strings you will see

"Have not found any log file for sshd jail", and Fail2ban will not start. Dis na old auth.log problem, and for Ubuntu 24.04 you go only see am if something don change the default settings — like pip install wey no get defaults-debian.conf, container wey no get journal, or one stray backend = auto wey you paste inside jail.local. If you dey use file backend wey no get /var/log/auth.log, the sshd jail no go fit find its log and the whole daemon go stop. fail2ban.log go show:

ERROR   Failed during configuration: Have not found any log file for sshd jail

Because that error na fatal one, the service no go ever start, and fail2ban-client status go show the next problem:

ERROR  Failed to access socket path: /var/run/fail2ban/fail2ban.sock. Is fail2ban running?

That "socket path" line no mean say Fail2ban don spoil — e mean say e no start because one jail no fit find its log. To fix both messages at once, just set backend = systemd inside [DEFAULT], wetin the Ubuntu package don already do for you.

Jail is active but Total failed never moves. The daemon dey run and e dey read the journal, but real failures dey pile up for journalctl -u ssh while the counter still dey stay for 0. First, check the obvious things: if you dey test from one address wey dey inside ignoreip, your own failures no go count by design. If no be that one, you fit dey use OpenSSH build wey the per-connection worker na sshd-session (9.8 and later), wey the journal _COMM na sshd-session instead of sshd, so the default match no go see am. Widen the match inside the [sshd] block:

[sshd]
enabled      = true
backend      = systemd
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session

Restart, try fail one login on purpose from one address wey no dey inside ignoreip, and check if Total failed finally dey increase.

You banned yourself: Connection refused. You leave your own address out of ignoreip, you try some bad logins, and now:

ssh: connect to host 10.0.0.10 port 22: Connection refused

The refusal, instead of just silent timeout, na the default reject verdict of the nftables action dey work — for you. Fix am like Step 6: unban yourself from one session wey dey another address wey no dey banned, or use the provider console — any session wey don open from the banned address go freeze too. After that, add your address to ignoreip so e no go happen again.

Fail2ban says an address is banned, but it can still connect. The counter for status sshd dey increase, but the address still dey reach port 22. Dis na mismatch between ban-action and firewall, and for Ubuntu 24.04, e almost always mean say you don change the working banaction = nftables with banaction = iptables-multiport wey you copy from old guide, for one box wey no get iptables layer. fail2ban.log go show:

fail2ban.actions [812]: ERROR  Failed to execute ban jail 'sshd' action 'iptables-multiport'

Delete that override and let the packaged nftables action work, or, if you dey manage the firewall through ufw and you want bans to show up for there, set banaction = ufw inside [DEFAULT]. Restart and check if the rule show with sudo nft list ruleset | grep f2b.

Fail2ban will not start after editing jail.local. One typo — like one stray heading or bad time value — go make the service refuse to start. Tell Fail2ban to check the config before e run:

sudo fail2ban-client -t

E go tell you the file and the jail wey get the problem, for example Errors in jail 'sshd'. Skipping..., so you fit fix the real source instead of to dey guess.

FAQ

Does the stock Fail2ban install on Ubuntu 24.04 actually ban SSH attacks?

Yes. The package carry /etc/fail2ban/jail.d/defaults-debian.conf, wey enable the sshd jail, set backend = systemd so e go read systemd journal instead of the missing /var/log/auth.log, and set banaction = nftables so Ubuntu firewall go enforce the bans. One simple apt install fail2ban protect SSH from first boot. Confirm am with sudo fail2ban-client status sshd and look for any number wey no be zero for Total failed.

Why is Fail2ban not banning anything on my box?

Check these three common reasons one by one. You fit dey test from address inside ignoreip, wey dem design make e no dey ban. You fit don spoil the working default by paste backend = auto inside jail.local from old guide, wey go break how e dey read journal for image wey no get auth.log. Or you fit dey inside container wey no get systemd journal to read at all. Check Total failed inside fail2ban-client status sshd: if e no dey increase while journalctl -u ssh show real failures, the jail dey read wrong place.

How do I unban my own IP address?

Run sudo fail2ban-client set sshd unbanip YOUR.IP.HERE, wey go give you 1 if e work, or run sudo fail2ban-client unban --all to clear all bans. If SSH don lock you out, use your provider web console or VNC console run the same command — the ban dey block every packet from your address to port 22, so even if you don open session already, e go stop to work. After that, add your address to ignoreip so e no go happen again.

What is the difference between jail.conf and jail.local?

jail.conf hold the original Fail2ban defaults and every time you upgrade package, e go overwrite am, so any change wey you make there go lost. The Debian/Ubuntu package dey add its own settings for top through jail.d/defaults-debian.conf. Your changes suppose dey inside jail.local, wey be say e dey read last and e go win over the others, and upgrade no dey touch am. Leave jail.conf as read-only reference.

Does Fail2ban replace key-based SSH authentication?

No. Fail2ban dey limit how many times person fit fail from one address; e no dey do anything against slow, distributed guess where every address dey stay below the threshold. Key-only authentication (PasswordAuthentication no) make password guessing impossible altogether, and Fail2ban go just help to reduce log noise and kick out scanners early. Run both, and if possible, keep SSH off the public internet entirely.