How to Secure SSH on Ubuntu/Debian (Keys, Fail2Ban, UFW)

SSH (Secure Shell) is the default entry point for managing Linux servers. Whether you’re running a VPS or a bare-metal dedicated server, weak SSH configurations can expose you to brute-force attacks, credential leaks, and unauthorized access. In 2025, botnets are continuously scanning the internet for servers with open port 22 and weak passwords. That’s why securing SSH is one of the first tasks you should perform on any Ubuntu or Debian system before moving it into production.

This guide will walk through advanced steps to secure SSH on Ubuntu/Debian using key-based authentication, Fail2Ban, and UFW firewall rules. These practices are based on real-world sysadmin workflows and CIS hardening checklists.

🔑 Step 1: Disable Password Authentication and Use SSH Keys

Password authentication is the weakest link in SSH security. Attackers can easily brute force passwords, especially for accounts like root. Instead, generate a public-private key pair and disable passwords entirely.

On your local machine:

ssh-keygen -t ed25519 -C "your_email@example.com"

This creates a key pair in ~/.ssh/id_ed25519. Then copy the key to the server:

ssh-copy-id username@server_ip

Edit /etc/ssh/sshd_config on the server and ensure:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Finally, restart SSH:

systemctl restart ssh

Pro tip: Always test with a second session before closing your root shell to avoid locking yourself out.

🚫 Step 2: Change Default SSH Port

While security-by-obscurity is not a replacement for real hardening, changing the default port from 22 reduces noise from automated scanners.

Port 2222

in /etc/ssh/sshd_config. Don’t forget to update UFW and monitoring tools accordingly.

🛡️ Step 3: Install and Configure Fail2Ban

Fail2Ban monitors log files for repeated failed login attempts and dynamically blocks IPs that look malicious.

apt update && apt install fail2ban -y

Create or edit jail configuration:

/etc/fail2ban/jail.local

[sshd]
enabled = true
port    = 2222
filter  = sshd
logpath = /var/log/auth.log
maxretry = 5
bantime = 3600

Restart the service:

systemctl enable --now fail2ban

Check active bans:

fail2ban-client status sshd

🔥 Step 4: Lock Down Access with UFW

Ubuntu and Debian ship with UFW (Uncomplicated Firewall), a front-end for iptables. Limit access to only the SSH port you configured and any application-specific ports.

ufw default deny incoming
ufw default allow outgoing
ufw allow 2222/tcp
ufw enable

You can also restrict SSH to specific IPs if you manage from a fixed location:

ufw allow from 203.0.113.10 to any port 2222 proto tcp

🔍 Step 5: Enable 2FA for SSH (Optional)

For high-security environments, enable two-factor authentication with Google Authenticator or Authy PAM modules.

apt install libpam-google-authenticator
google-authenticator

Then edit /etc/pam.d/sshd to add:

auth required pam_google_authenticator.so

This ensures even if your key is stolen, an attacker would still need a one-time token.

📈 Step 6: Monitor and Audit SSH Access

Keep an eye on SSH logins with:

journalctl -u ssh --since "1 hour ago"
last -a | head -n 20

Integrating these logs into Zabbix, Grafana, or ELK helps track patterns and detect anomalies.

✅ Conclusion

Securing SSH is not just about one tweak — it’s a layered approach. By combining key-based authentication, Fail2Ban, UFW rules, and optional 2FA, you can drastically reduce your attack surface. In production-grade setups, add monitoring and central logging to ensure you catch anomalies before they become incidents.

At WeHaveServers.com, all our VPS and Dedicated Servers ship with root SSH access, giving you full control — but we recommend applying these hardening steps before deploying workloads to production.

❓ FAQ

Should I disable root SSH login?

Yes, always. Create a non-root user with sudo privileges and disable direct root login for better security.

What’s better: changing SSH port or using Fail2Ban?

Changing the port reduces noise, but Fail2Ban actively blocks brute-force attempts. For best results, use both.

How do I recover if I lock myself out?

Use your provider’s recovery console (IPMI, iDRAC, or VNC). Always test new SSH configs in a separate session first.

Is key authentication enough for production?

For most setups, yes. For sensitive environments, combine keys with 2FA and strict firewall rules.

Can I use UFW and Fail2Ban together?

Yes, they complement each other. UFW sets the baseline policy, Fail2Ban reacts dynamically to attacks.