Secure your Ubuntu Server SSH with Fail2Ban and UFW

If you run Ubuntu servers in Toronto, Vancouver, Montreal or anywhere else, the SSH port is the most common target for attackers. This concise, command-first guide shows how to secure SSH using UFW (Uncomplicated Firewall) and Fail2Ban. Commands are safe for Ubuntu LTS releases and include practical whitelist examples for Canadian offices and home devs.

Why protect SSH with UFW + Fail2Ban?

UFW enforces network-level rules (who can reach port 22). Fail2Ban blocks repeated login attempts by adding temporary bans. Together they: reduce brute-force attacks, prevent credential stuffing, and minimize noise in logs so you can focus on real incidents.

Prerequisites

Ubuntu server (18.04, 20.04, 22.04 or later)
root or sudo access
SSH access from a stable IP (or console access via cloud provider)
Optionally: client machine to generate SSH key pairs

Step 1 — Update and install UFW + Fail2Ban

Run the following commands to update packages and install both tools:

sudo apt update && sudo apt upgrade -y
sudo apt install -y ufw fail2ban

Confirm versions if you need to match documentation:

ufw --version
fail2ban-client --version

Step 2 — Configure UFW to protect SSH

Before enabling UFW, allow existing SSH connections so you don't lock yourself out.

# Allow OpenSSH (port 22) before enabling UFW
sudo ufw allow OpenSSH
# Or explicitly: sudo ufw allow 22/tcp

Use rate limiting for unknown hosts

Use UFW's limit rule to throttle new connections from the same IP:

sudo ufw limit OpenSSH
# This blocks an IP for a short period if it attempts many connections quickly

Whitelist office or home IPs (Canadian examples)

Whitelist static IPs for trusted locations. Replace example IPs with your real public addresses.

Toronto office (example): 203.0.113.45
Vancouver developer home (example): 198.51.100.10
Montreal CI server (example): 192.0.2.25

# Whitelist a single IP
sudo ufw allow from 203.0.113.45 to any port 22 proto tcp
# Allow a /24 office subnet
sudo ufw allow from 198.51.100.0/24 to any port 22 proto tcp

Other Canadian examples: if your cloud load balancer is in Calgary or Halifax, whitelist its IP range; if your remote admin is in Winnipeg, add their stable IP.

Enable UFW safely

After allowing SSH and any other necessary services (HTTP/HTTPS for web servers), enable UFW:

sudo ufw enable
sudo ufw status verbose

If you'd like SFWeb to set up and test secure firewall rules across multiple servers (Toronto, Montreal, Ottawa), our IT Services team can help with one-time deployments and ongoing monitoring.

Step 3 — Configure Fail2Ban for SSH

Create a local Fail2Ban configuration to avoid overwriting defaults. We'll enable the sshd jail and use UFW as the banning action so Fail2Ban and UFW work together.

sudo tee /etc/fail2ban/jail.local > /dev/null <<'EOF'
[sshd]
enabled = true
port    = ssh
filter  = sshd
logpath = /var/log/auth.log
maxretry = 5
findtime = 600
bantime = 3600
banaction = ufw
EOF

# Restart to apply
sudo systemctl restart fail2ban

Key options:

maxretry: number of failed attempts before ban
findtime: window (seconds) in which failures count
bantime: seconds to ban (use longer for production; e.g. 86400 for 24h)
banaction: use ufw so Fail2Ban issues UFW deny rules

Protect alternate SSH ports

If you run SSH on a non-standard port (e.g. 2222), add a jail override:

# Add in /etc/fail2ban/jail.local
[sshd-alt]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
banaction = ufw

Step 4 — Improve SSH itself (keys, disable passwords)

Use key-based authentication and disable password auth to dramatically reduce brute-force success.

# On your local machine: generate a key if you don't have one
ssh-keygen -t ed25519 -C "admin@yourdomain"
# Copy public key to server
ssh-copy-id -i ~/.ssh/id_ed25519.pub username@your-server-ip

Then edit SSH server settings:

sudo sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
# Restart sshd
sudo systemctl restart sshd

Test a separate session before closing your current SSH window; avoid locking yourself out. If your team is distributed (for example admins in Quebec City, Halifax and Calgary), ensure all admin public keys are installed before disabling passwords.

Testing and monitoring

Verify Fail2Ban and UFW are working:

# Fail2Ban status
sudo fail2ban-client status
sudo fail2ban-client status sshd
# View UFW rules
sudo ufw status numbered
# Watch auth log live for suspicious attempts
sudo tail -f /var/log/auth.log

Try a controlled failed login from a test machine (not a production client) to confirm bans apply. If you use cloud providers in Toronto or Vancouver, double-check firewall/SG rules at provider level too.

Checklist — Quick deploy steps

Update packages: sudo apt update && sudo apt upgrade -y
Install tools: sudo apt install ufw fail2ban -y
Allow SSH in UFW: sudo ufw allow OpenSSH
Enable UFW: sudo ufw enable
Create /etc/fail2ban/jail.local with SSH jail and banaction = ufw
Enable key-based SSH and disable password authentication after testing
Test bans and monitor logs: sudo fail2ban-client status sshd

Common Mistakes

Enabling UFW before allowing SSH. Always allow OpenSSH first to avoid lockout.
Disabling password auth before installing keys for all admins — keep a rescue console or cloud provider access ready.
Relying on Fail2Ban alone. It's best when paired with UFW or provider security groups.
Whitelisting a dynamic home IP without a plan — use a dynamic DNS solution or VPN for stable access.
Assuming non-standard ports are a replacement for hardening. They only reduce noise slightly.

If you'd like us to implement this on multiple servers (for example an e-commerce stack across Montreal, Toronto and Calgary), SFWeb can deploy, test and automate the setup — see our Automation Solutions page for scheduled hardening and rollback scripts.

FAQ

Will I get locked out after enabling UFW?

Only if you forget to allow SSH first. Always run sudo ufw allow OpenSSH before sudo ufw enable. Keep an active session when testing new firewall rules or have console access through your cloud provider.

Can Fail2Ban and UFW work together?

Yes. Configure Fail2Ban's banaction to ufw (as shown). Fail2Ban will add UFW deny rules instead of manipulating iptables directly.

How do I whitelist an admin with a dynamic IP?

Options: use a VPN with a stable exit IP, install the admin's SSH key and restrict by key only, or use dynamic DNS combined with a small script to update UFW rules. For small teams in Ottawa or Winnipeg, a VPN is typically the most reliable option.

Does this stop targeted attacks from known IPs in Canada?

UFW + Fail2Ban reduce automated and opportunistic attacks. For targeted attackers you should combine network rules with monitoring, SSH key management, and possibly IP allowlists for critical services. SFWeb's Small Business Solutions can help design multi-layered protection if needed.

What logs should I keep and for how long?

Keep authentication logs (/var/log/auth.log) and Fail2Ban logs. Retain at least 30 days for standard operations; extend retention if you need forensic capability. Use central logging (ELK/CloudWatch) for multi-server setups, especially across regions like Toronto, Vancouver and Montreal.

Conclusion

Combining UFW and Fail2Ban gives strong, low-maintenance protection for SSH on Ubuntu. Implementing the steps above (allow SSH, enable UFW, configure Fail2Ban with banaction=ufw, enforce key-based auth) will stop most automated attacks and reduce noise. If you manage fleets in Toronto, Vancouver, Calgary, Halifax, Montreal or Winnipeg and want this rolled out consistently, contact SFWeb for deployment and monitoring options.

Need a hand implementing this across multiple servers or integrating with your CI/CD pipelines? Reach out via our contact page — our team can secure, test and automate the process end-to-end.