Hardening SSH: The Five Lines That Matter

01Why Most SSH Guides Overdo It

Open any "SSH hardening" tutorial and you'll find a wall of directives — cipher suites, MAC algorithms, LoginGraceTime, MaxStartups, AllowAgentForwarding, and twenty more. Most of it is correct. Almost none of it is urgent. The gap between a default SSH config and a hardened one can be closed, meaningfully, with five edits. Everything else is refinement.

Skip the forty-point checklist.

The file you're editing lives at /etc/ssh/sshd_config. On systemd-based distributions — which means Debian, Ubuntu, Fedora, Arch, openSUSE, and nearly everything else — you reload the daemon after changes with sudo systemctl reload sshd. On some distributions the service is named ssh rather than sshd; check with systemctl status ssh if the first form fails. Make a backup before you start: sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak. That one minute of caution has saved many weekends.

02The Five Changes

1. Disable root login

PermitRootLogin no

Root is the one account guaranteed to exist on every Linux machine. Automated scanners know this, and they hammer it constantly. Disabling direct root login means an attacker must first compromise a regular user account and then escalate — two hurdles instead of one. You should be doing privileged work via sudo from a named user account anyway. If you're on a VPS from a provider that drops you straight into a root shell on first boot, create a regular user, add it to the sudo group, confirm you can log in as that user, then flip this directive.

2. Disable password authentication

PasswordAuthentication no

This is the single highest-leverage change on the list. Password authentication is brute-forceable; a key pair is not. An Ed25519 private key sitting on your local machine cannot be guessed across the network no matter how long the attacker runs their script. Before you set this, make sure your public key is installed on the server (~/.ssh/authorized_keys), and test key-based login in a second terminal while keeping your first session open. Locking yourself out of a remote machine because you disabled passwords before confirming keys work is a rite of passage nobody needs to repeat.

Generate a key pair locally if you haven't already:

ssh-keygen -t ed25519 -C "your-label"
ssh-copy-id user@yourserver

Ed25519 is preferred over the older RSA for new keys — smaller, faster, and considered stronger for equivalent key lengths.

3. Disable empty passwords

PermitEmptyPasswords no

This one should be no by default, but defaults are not guarantees — they vary by distribution, can be changed by provisioning scripts, and occasionally get reset by package upgrades touching the config file. Make it explicit. An account with no password and SSH access is an open door; this directive slams it regardless of what passwd says about any given user.

4. Limit which users can log in

AllowUsers alice bob deploy

The AllowUsers directive creates a whitelist. Only the named accounts can authenticate over SSH, full stop — even if another account has a valid key in its authorized_keys. On a personal server this might be just your own username. On a small team setup it's the handful of humans plus any service accounts that genuinely need remote access. The inverse directive DenyUsers also exists, but a whitelist is safer than a blacklist: you explicitly grant access rather than trying to enumerate every account you want to block.

If you manage groups rather than individual users, AllowGroups works the same way — add users to a group like sshusers and name that group in the directive.

5. Change the default port

Port 2222

Controversy lives here. Security purists correctly point out that moving SSH off port 22 is security through obscurity — it doesn't make the service more secure, it just makes it quieter. That's true. It's also genuinely useful: the automated scanning noise that hits port 22 around the clock drops to near-zero on a non-standard port. Your logs become readable again. The signal-to-noise ratio in journalctl -u sshd goes from exhausting to informative.

Pick something above 1024 and not obviously SSH-adjacent (avoid 2222 in production — it's too common; something like 47291 is more effective). Remember to update your firewall rules when you change the port. If you use ufw, the sequence is straightforward: allow the new port before denying or removing the old one, or you'll lock yourself out.

03After You Edit

Save the file, then validate your syntax before reloading:

sudo sshd -t

A silent exit means the config is clean. Any errors are printed clearly. Only then run sudo systemctl reload sshd. Keep your existing session open, open a new terminal, and confirm you can connect with the new settings. If something went wrong, your open session is your lifeline back to the original config.

Five lines. Reload. Test. The forty-point checklist will still be there if you want it — but your server is already doing the work that matters.