Linux Server Security: SSH Keys and Fail2Ban Automation

Last month, I checked the /var/log/auth.log on a fresh VPS I’d spun up for a side project. Within forty minutes of the public IP being active, I counted over 200 failed login attempts from various botnets. It’s a harsh reminder that the public internet is a noisy place, and if you aren’t running a solid Linux server security strategy, your machine is basically a target.

I’ve spent years cleaning up compromised servers, and the fix is almost always the same: stop relying on passwords and start automating your defense.

Hardening SSH Access

The first step in any server hardening guide is disabling password authentication. Passwords can be guessed, intercepted, or leaked. SSH keys, however, are mathematically impractical to brute-force.

Before you touch anything, make sure you have your public key (~/.ssh/id_rsa.pub) copied to the server’s ~/.ssh/authorized_keys file. Test your connection in a new terminal window before you close your current one. If you lock yourself out, you’ll be relying on your cloud provider’s VNC console, which is never fun.

Once you’re in, edit your /etc/ssh/sshd_config file:

Bash
# Disable password authentication
PasswordAuthentication no

# Disable root login (optional but recommended)
PermitRootLogin no

# Disable empty passwords
PermitEmptyPasswords no

After modifying the file, verify the syntax and restart the service:

Bash
sudo sshd -t
sudo systemctl restart ssh

Following these SSH configuration best practices usually drops your unauthorized login attempts to zero immediately. If you’re interested in broader hardening, you can also automate audits with Lynis and fail2ban to ensure your base OS configuration remains secure over time.

Implementing Fail2Ban for Automated Defense

Even with keys, bots will still hammer your ports, which wastes CPU cycles and fills your logs. A proper Fail2Ban setup acts as a dynamic firewall, automatically blocking IPs that exhibit malicious behavior.

Installing it is straightforward on Debian/Ubuntu systems:

Bash
sudo apt update && sudo apt install fail2ban -y

Fail2Ban works by scanning logs for patterns. We’ll create a local configuration file to override the defaults. Never edit the jail.conf file directly; use a jail.local file instead so your changes persist through package updates.

Create /etc/fail2ban/jail.local:

INI
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 1h

This configuration tells Fail2Ban to ban any IP that fails to authenticate via SSH three times for one hour. After saving, restart the service:

Bash
sudo systemctl restart fail2ban

Comparing Authentication Methods

Managing Logs and Hardening Strategy

Security isn't a "set it and forget it" task. Once you have Fail2Ban running, you'll notice your log files growing significantly. I recommend implementing logrotate configuration mastery to ensure that your security logs don't swallow your disk space.

If you are running web applications on these same servers, remember that SSH is only one attack vector. You should also be looking at security best practices in React or handling session tokens carefully, as preventing session fixation is just as critical as locking down the OS.

Frequently Asked Questions

1. What if I lose my SSH private key? You will be locked out. Always keep a backup of your private keys in a secure, offline location like an encrypted vault. Some cloud providers allow you to inject a new public key via their API/console if you lose access, but don't count on it.

2. Is bantime = 1h enough? For most automated bots, yes. If you are being targeted by a persistent manual attacker, you might want to increase this to 24h or even use a permanent ban list, though that can become a management headache.

3. Does Fail2Ban work with UFW? Yes. By default, Fail2Ban interacts with iptables. If you use UFW, make sure Fail2Ban is configured to use the ufw action in your jail.local file to ensure the rules are synced correctly.

I'm still tinkering with my Fail2Ban "recidive" jail, which bans IPs that repeatedly trigger the standard SSH jail. It’s a bit aggressive, but it’s helped me cut down on the noise from high-volume scanning networks. Just be careful—if you test this from a dynamic IP at home, you might accidentally lock yourself out of your own server for a week.