Fail2ban for Beginners: Protect SSH on a Linux Home Server

SSH is usually the front door of a Linux home server.

And if that door is reachable from the network, something will eventually knock on it.

Sometimes it is you.

Sometimes it is a script from the other side of the planet trying admin, root, test, ubuntu, oracle, minecraft, and whatever else is in its boring little dictionary.

This is where Fail2ban is useful.

Fail2ban watches logs for repeated failed login attempts and temporarily bans the source IP address using firewall rules. It is not magic, and it is not a replacement for proper SSH hardening, but it is a very useful extra layer for a Linux home server.

This post is a beginner-friendly guide to Fail2ban for SSH on a Linux home server. The goal is not to build an enterprise security platform. The goal is to reduce brute-force noise, protect SSH, and avoid locking yourself out of your own machine.

If you are building a secure Linux box, also see my Linux Home Server Security Checklist and my guide to UFW Firewall Rules for Home Servers.

Fail2ban is not the lock on the door. It is the person who stops someone from trying the handle 500 times.

1. What Fail2ban actually does

Fail2ban works with three main ideas:

Filter: what log messages to look for;
Jail: which service to protect and what limits to use;
Action: what to do when the limit is reached, usually banning an IP address.

For SSH, Fail2ban watches authentication logs. If one IP address fails too many login attempts inside a defined time window, Fail2ban bans that IP for a period of time.

Typical settings:

maxretry = how many failures are allowed;
findtime = the time window for counting failures;
bantime = how long the IP stays banned.

Example:

maxretry = 5
findtime = 10m
bantime = 1h

This means: if the same IP fails 5 times within 10 minutes, ban it for 1 hour.

Simple and effective.

2. What Fail2ban does not replace

Before installing Fail2ban, it is important to be honest about what it does not fix.

Fail2ban does not replace:

SSH keys;
strong passwords;
disabling root login;
disabling SSH password login where possible;
UFW firewall rules;
updates;
backups;
common sense.

Ubuntu’s OpenSSH documentation notes that OpenSSH supports several authentication methods, including password authentication and public key cryptography. For home servers, SSH keys plus restricted access are usually much stronger than relying on passwords alone. See Ubuntu’s OpenSSH server documentation.

So the correct order is usually:

Use SSH keys.
Disable direct root login.
Disable password authentication if practical.
Restrict SSH with UFW or a VPN.
Add Fail2ban as another layer.

If SSH is already locked down to your LAN only, Fail2ban may not see much action. That is fine. Boring is good.

3. Install Fail2ban

On Ubuntu, Debian, Linux Mint and similar systems:

sudo apt update
sudo apt install fail2ban

Check if the service is running:

sudo systemctl status fail2ban

Enable it at boot if needed:

sudo systemctl enable fail2ban

Start it:

sudo systemctl start fail2ban

Check the installed version:

fail2ban-client version

4. Do not edit `jail.conf` directly

Fail2ban includes default configuration files. You may see:

/etc/fail2ban/jail.conf

Do not edit that file directly.

Instead, create or edit:

/etc/fail2ban/jail.local

The .local file is used for your local overrides, so package updates are less likely to overwrite your changes.

Create it:

sudo nano /etc/fail2ban/jail.local

For a basic SSH setup, add this:

[sshd]
enabled = true
port = ssh
filter = sshd
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

Save the file.

Restart Fail2ban:

sudo systemctl restart fail2ban

Check status:

sudo fail2ban-client status

Then check the SSH jail:

sudo fail2ban-client status sshd

5. Understand the SSH jail settings

Here is the basic SSH jail again:

[sshd]
enabled = true
port = ssh
filter = sshd
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

What each line means:

[sshd]: this jail protects SSH;
enabled = true: turns the jail on;
port = ssh: uses the SSH service port, normally 22;
filter = sshd: uses Fail2ban’s SSH filter;
backend = systemd: reads logs from systemd journal;
maxretry = 5: allows 5 failures;
findtime = 10m: counts failures inside 10 minutes;
bantime = 1h: bans the IP for 1 hour.

For most home servers, that is a reasonable starting point.

If your SSH runs on a custom port, change the port:

port = 2222

Or:

[sshd]
enabled = true
port = 2222
filter = sshd
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

Do not make bans extremely aggressive on your first day. You want protection, not accidental lockouts.

6. Check that Fail2ban sees the SSH jail

After restarting Fail2ban:

sudo fail2ban-client status

You should see something like:

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

Then:

sudo fail2ban-client status sshd

Example output:

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

The exact output can vary by distribution, but the important part is that the sshd jail exists and is active.

7. Check authentication logs

On many systemd-based systems, SSH logs can be viewed with:

sudo journalctl -u ssh --since "1 hour ago"

Or:

sudo journalctl -u sshd --since "1 hour ago"

Depending on the distribution, the service may be called ssh or sshd.

You can check both:

systemctl status ssh
systemctl status sshd

On Debian/Ubuntu systems, you may also have:

/var/log/auth.log

Check failed attempts:

sudo grep "Failed password" /var/log/auth.log

Or with journalctl:

sudo journalctl -u ssh | grep "Failed password"

If you see many failed attempts from the same IP, Fail2ban should eventually ban that IP based on your jail settings.

8. Test carefully without locking yourself out

Testing Fail2ban by intentionally failing SSH logins can work, but be careful.

Do not test from your only admin machine if you have no console access.

Safer testing options:

test from another device on the LAN;
make sure you have physical access to the server;
keep an existing SSH session open;
know how to unban your IP;
use a short bantime during testing.

Temporary testing jail:

[sshd]
enabled = true
port = ssh
filter = sshd
backend = systemd
maxretry = 3
findtime = 5m
bantime = 5m

Restart Fail2ban:

sudo systemctl restart fail2ban

Then try a few failed SSH logins from a test machine.

Check the jail:

sudo fail2ban-client status sshd

If your test IP appears in the banned list, Fail2ban is working.

9. Unban yourself

If you ban your own IP, do not panic.

From an existing SSH session or local console, check banned IPs:

sudo fail2ban-client status sshd

Unban an IP:

sudo fail2ban-client set sshd unbanip 192.168.1.50

Replace 192.168.1.50 with the banned IP.

You can also restart Fail2ban, but unbanning the specific IP is cleaner:

sudo systemctl restart fail2ban

During your first setup, keep bantime short until you know everything works.

10. Add your trusted IP to ignoreip

If you always administer the server from a trusted LAN range, you can tell Fail2ban to ignore it.

In /etc/fail2ban/jail.local:

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24

[sshd]
enabled = true
port = ssh
filter = sshd
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

This tells Fail2ban not to ban localhost or your local network.

Change 192.168.1.0/24 to your real LAN range.

This is useful for home servers, but do not add huge public ranges or random addresses just to avoid fixing login problems.

After changing the config:

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

11. Combine Fail2ban with UFW

Fail2ban and UFW solve different problems.

UFW decides who can reach the SSH port in the first place.

Fail2ban reacts to repeated failed attempts.

For a home server, a good UFW rule might be:

sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp

This means only your LAN can reach SSH.

If SSH must be reachable from outside, you might allow the SSH port more broadly:

sudo ufw allow 22/tcp

But I would avoid that where possible. A VPN is usually cleaner.

Check UFW:

sudo ufw status verbose

Check Fail2ban:

sudo fail2ban-client status sshd

Both should make sense together.

12. Choose sensible ban settings

Do not start with crazy values.

A beginner-friendly setup:

maxretry = 5
findtime = 10m
bantime = 1h

A slightly stricter setup:

maxretry = 4
findtime = 15m
bantime = 6h

A more annoying-for-attackers setup:

maxretry = 3
findtime = 30m
bantime = 24h

For a home server, I would start mild and tighten later if needed.

If you use SSH keys and password login is disabled, failed password attempts may already be less useful to attackers. Fail2ban still helps reduce noise and repeated abuse.

13. Enable persistent bans carefully

By default, bans may not survive service restarts depending on your setup and version.

For most home servers, that is not a big problem. Temporary bans are usually enough.

Some people configure longer bans or persistent bans. That can be useful for internet-facing systems, but be careful with it.

Long bans can create two issues:

you may accidentally ban yourself for too long;
IP addresses can change, especially on consumer networks.

For a beginner homelab, I prefer shorter bans at first:

bantime = 1h

Then increase later if needed:

bantime = 24h

Do not make your first config a permanent-ban trap.

14. Check Fail2ban logs

Fail2ban logs are useful when troubleshooting.

Common log location:

/var/log/fail2ban.log

View recent entries:

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

Follow live:

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

With systemd:

sudo journalctl -u fail2ban --since "1 hour ago"

Look for lines showing:

jail started;
IP found;
IP banned;
IP unbanned;
configuration errors;
missing log files;
backend problems.

If Fail2ban is not banning anything, logs are the first place to look.

15. Troubleshooting: jail is not starting

Check Fail2ban service status:

sudo systemctl status fail2ban

Check logs:

sudo journalctl -u fail2ban --since "30 minutes ago"

Test client communication:

sudo fail2ban-client ping

Expected:

Server replied: pong

If there is a syntax error in jail.local, Fail2ban may fail to start or ignore parts of the config.

Open the file and check spacing, section headers and values:

sudo nano /etc/fail2ban/jail.local

Common mistakes:

missing section header like [sshd];
using smart quotes copied from a website;
wrong indentation in strange places;
wrong backend;
wrong port;
wrong service name.

16. Troubleshooting: no bans happen

If Fail2ban is running but not banning, check the SSH jail:

sudo fail2ban-client status sshd

Check SSH logs:

sudo journalctl -u ssh --since "1 hour ago"
sudo journalctl -u sshd --since "1 hour ago"

Check whether your system uses ssh or sshd:

systemctl list-units | grep ssh

If using backend = systemd, make sure the jail is matching the right journal unit.

You can also try removing the backend line temporarily and let Fail2ban choose the default:

[sshd]
enabled = true
port = ssh
filter = sshd
maxretry = 5
findtime = 10m
bantime = 1h

Restart and check again:

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

On some systems, logs may be in /var/log/auth.log; on others, journalctl is the better path.

17. Troubleshooting: I got locked out

If you are locked out over SSH, you need another way in:

physical keyboard and monitor;
VM console;
hosting provider web console;
existing SSH session;
another trusted IP that is not banned.

Once in, check banned IPs:

sudo fail2ban-client status sshd

Unban your IP:

sudo fail2ban-client set sshd unbanip your-ip-address

Or temporarily stop Fail2ban:

sudo systemctl stop fail2ban

Then fix your config.

To reduce lockout risk:

use ignoreip for your LAN;
keep bantime short during testing;
keep a working SSH session open;
do not test from your only admin device;
make sure UFW and Fail2ban rules make sense together.

18. Protecting SSH when using a custom port

If your SSH server listens on port 2222, first confirm it:

sudo ss -tulpn | grep ssh

UFW rule example:

sudo ufw allow from 192.168.1.0/24 to any port 2222 proto tcp

Fail2ban jail:

[sshd]
enabled = true
port = 2222
filter = sshd
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

Restart:

sudo systemctl restart fail2ban

Check:

sudo fail2ban-client status sshd

Changing SSH ports can reduce noise from basic bots, but it is not real security by itself.

Use keys, disable root login, firewall the port, and use Fail2ban as another layer.

19. SSH hardening settings to use with Fail2ban

Create a separate SSH config file:

sudo nano /etc/ssh/sshd_config.d/99-homelab-hardening.conf

Example:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
X11Forwarding no
AllowUsers youruser

Replace youruser with your real username.

Test the config:

sudo sshd -t

Reload SSH:

sudo systemctl reload ssh

Keep an existing session open while testing from another terminal.

With this setup, Fail2ban is not your only protection. It is just one layer in a better SSH setup.

20. Should Fail2ban protect other services?

Yes, but start with SSH.

Fail2ban can protect many services if filters and logs are available, such as:

nginx;
apache;
postfix;
dovecot;
some web login pages;
reverse proxy authentication;
custom application logs.

But each service needs the correct filter, log source and action.

For beginners, do not enable every jail you find on the internet. Start with SSH, understand how it works, then expand slowly.

A bad Fail2ban rule can ban legitimate users, miss attacks, or just create confusion.

21. My simple Fail2ban setup for a home server

This is the kind of setup I would use for a basic Linux home server:

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24
bantime = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
port = ssh
filter = sshd
backend = systemd

Save as:

/etc/fail2ban/jail.local

Restart:

sudo systemctl restart fail2ban

Check:

sudo fail2ban-client status
sudo fail2ban-client status sshd

This setup ignores the local LAN, protects SSH, and uses mild ban settings.

If your SSH is exposed to the internet, you may want stricter settings later.

22. Monthly Fail2ban maintenance

Once in a while, check what Fail2ban has been doing:

sudo fail2ban-client status sshd
sudo tail -100 /var/log/fail2ban.log
sudo journalctl -u fail2ban --since "30 days ago"

Also check SSH logs:

sudo journalctl -u ssh --since "30 days ago"

And firewall status:

sudo ufw status verbose

Ask:

Is SSH still exposed where I expect?
Are there many failed attempts?
Are bans happening?
Did I accidentally ignore too much?
Did my LAN range change?
Did I change the SSH port and forget to update Fail2ban?

A simple monthly check is enough for most home servers.

23. Common beginner mistakes

Thinking Fail2ban replaces SSH keys

It does not. Use SSH keys where possible.

Leaving root login enabled

Disable direct root SSH login unless you have a very specific reason.

Using very long bans immediately

Start with shorter bans until you know the setup works.

Testing from your only admin machine

That is how you lock yourself out and learn humility.

Forgetting UFW

Fail2ban reacts after failures. UFW can prevent unwanted clients from reaching the port at all.

Ignoring logs

If Fail2ban is not working, logs usually explain why.

Final thoughts

Fail2ban is a good tool for Linux home servers because it is simple, practical and easy to understand once you learn the basics.

It watches logs. It counts failures. It bans noisy IPs.

That is enough to reduce a lot of SSH brute-force noise.

But it should be part of a bigger SSH security setup:

use SSH keys;
disable root login;
disable password login if practical;
restrict SSH with UFW or a VPN;
keep the server updated;
use Fail2ban as another layer;
check logs occasionally.

The best home server security is boring and understandable.

A clean SSH config, a simple UFW rule, and a basic Fail2ban jail will do more than a pile of tools you never check.

Start small. Test carefully. Keep a way back in.

And never test lockout tools from the only machine that can unlock the door.

IT Random Stuff