Overview
Hey folks! Let’s talk about SSH—the go-to tool for managing remote Linux servers. It’s super useful, but honestly, out-of-the-box, it’s like a magnet for automated attacks. Here’s what I’ve learned as an L3 Support Engineer about locking down SSH:
1) Ditch passwords. Go with Key-Based Authentication. It’s way stronger.
2) Don’t make it easy for attackers. Change the default port to reduce automated bot noise (not a real security boundary) and turn off root login.
3) Set up Fail2Ban. It automatically blocks brute-force attempts, so you don’t have to keep an eye on logs all day.
4) Double-check your setup. Audit your config so you don’t accidentally lock yourself out. That’s it—these steps make SSH a lot tougher for attackers to mess with.
Step 1: Ditch Passwords for SSH Keys
Passwords just don’t cut it when it comes to keeping your server safe. Automated bots hammer away, guessing thousands of passwords every minute. But if you switch to SSH keys, brute-force attacks basically stop being a problem.
Making a Secure Key Pair
Open up your local machine and make yourself a strong, modern key with the Ed25519 algorithm. It’s not only faster than old-school RSA, it’s a lot more secure.
ssh-keygen -t ed25519 -C "admin@example.com"
Step 2: Change the default port and turn off root login
Once you’ve set up your keys, it’s time to lock the door for real and ditch passwords altogether. We're going to tweak the /etc/ssh/sshd_config file so only key-based logins work.
Heads up—leave one SSH session running while you’re editing. If you mess something up and restart the service, you don’t want to lock yourself out.
Go ahead and open up the config file:
sudo vi /etc/ssh/sshd_config
Essential Security Tweaks
Update the following directives in the file:
# 1. Change the default port to dodge automated bots
Port 2222
# 2. Disable root login. Always use a sudo user instead.
PermitRootLogin no
# 3. Disable password authentication entirely
PasswordAuthentication no
# 4. Limit the number of failed attempts before disconnection
MaxAuthTries 3
# 5. Only allow specific users to log in (Whitelist)
AllowUsers your_username
After saving the file, check the configuration for syntax errors:
sudo sshd -t
If there is no output, restart the service:
sudo systemctl restart ssh
Step 3: Set up Fail2Ban.
Even after you move SSH to a different port and turn off password access, bots still sniff around. Your logs will fill up with failed attempts. That’s where Fail2Ban comes in. It watches for trouble and blocks shady IPs automatically, so you don’t have to babysit your server.
Installation
First, install the service on your server:
sudo apt update && sudo apt install fail2ban -y
Configuration
Instead of editing the main config, we create a .local file to override the defaults. This ensures your settings stay intact during updates.
sudo nano /etc/fail2ban/jail.local
Add the following configuration for your hardened SSH service:
[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
findtime = 10m
bantime = 1h
1) maxretry: Number of failures before a ban.
2) bantime: How long the offender is blocked (1 hour in this case).
Step 4: Restart the service to turn on protection
sudo systemctl restart fail2ban
Want to see which IPs Fail2Ban has blocked or check your jail’s status? Run:
sudo fail2ban-client status sshd
Conclusion
Locking down your servers isn’t something you set and forget. Ditching password logins, switching up default ports, and letting Fail2Ban handle brute force attacks—these moves shut the door on most lazy hackers.
Honestly, this is just the baseline for any serious server. If you’re ready to bump things up, try adding Two-Factor Authentication or set up a VPN or jump host for extra protection.
Got a favorite SSH security tip? Or maybe you’ve run into a bizarre lockout? Drop your stories in the comments—I’d love to hear them.
Top comments (0)