How to Secure SSH on Your Linux Server

Check your auth log right now: grep 'Failed password' /var/log/auth.log | wc -l. On a fresh VPS that has been online for a week, that number is often in the thousands. Bots scan the entire IPv4 space around the clock, and port 22 with password login is exactly what they want. Here is how I lock down SSH on every server I set up, in the order I actually do it.

Switch to key-based login first

Do this before anything else, because the last step disables passwords entirely. On your local machine:

ssh-keygen -t ed25519 -C "laptop-2026"
ssh-copy-id user@your-server-ip

Ed25519 keys are shorter and faster than RSA, and every OpenSSH release since 6.5 supports them. Test the key login in a new terminal. Do not skip that test — if the key does not work and you have already turned off passwords, you are locked out.

Edit sshd_config

Open /etc/ssh/sshd_config and change these five lines:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 20

Then reload: systemctl reload sshd. Keep your current session open while you verify a fresh connection works. Ubuntu 22.10 and newer also read files from /etc/ssh/sshd_config.d/, and a file there can silently override your edits — run sshd -T | grep -i passwordauth to confirm what the daemon actually loaded.

Should you change the port?

Moving SSH to something like port 2222 cuts log noise by 90% or more, but it stops zero targeted attackers. I change it on personal boxes just to keep the logs readable, and leave it at 22 on team servers where nonstandard ports confuse people. If you do change it, update the firewall in the same minute:

ufw allow 2222/tcp
ufw delete allow 22/tcp

Rate-limit what remains

Even with keys only, bots still burn CPU on connection attempts. Two cheap fixes. UFW has a built-in limit rule that blocks an IP after 6 attempts in 30 seconds:

ufw limit 22/tcp

Fail2ban goes further and bans repeat offenders for as long as you want. A minimal /etc/fail2ban/jail.local:

[sshd]
enabled = true
maxretry = 3
bantime = 6h

Optional: restrict who and where

If only two people need SSH, say so explicitly in sshd_config: AllowUsers deploy admin. And if your team all connects through one office IP or a VPN, the strongest move is a firewall rule that drops port 22 from everywhere else: ufw allow from 203.0.113.0/24 to any port 22. Nothing beats an attack surface the attacker cannot reach.

FAQ

I locked myself out. Now what?
Use your VPS provider’s web console (VNC or serial) — it does not go through SSH. Log in there, revert the last change in sshd_config, and reload the service.

Is disabling root login really necessary if passwords are already off?
Yes. It removes the one username every bot tries first, and it forces an audit trail: each admin logs in as themselves and escalates with sudo.

Do I still need Fail2ban after switching to keys?
Your server is safe without it, but your logs and CPU are not. Fail2ban keeps thousands of daily junk attempts from drowning out the entries you actually need to read.

Got a hardening trick I missed, or a lockout story to share? Leave a comment on fenij.com.