Locking Down SSH

SSH Hardening That Actually Matters

SSH is the front door to almost everything you run yourself, a home lab box, a VPS, a server sitting on a rack in a closet. It's also the single most scanned, most brute-forced service on the internet. The good news is that the handful of changes that actually matter here are quick, well understood, and don't require you to become a security engineer to get right.

Changing the Port Is Theater, Not Security

Moving SSH off port 22 does exactly one thing: it drops you out of the lowest-effort, dumbest mass scans that only ever check the default port. It does nothing against anyone actually targeting you, and a full port scan finds your real port in seconds regardless of what you picked. Change it if you want quieter logs, that's a legitimate reason, but don't mistake it for a security control. Everything below this is the actual security control.

Keys Over Passwords, No Exceptions

Password authentication is guessable, phishable, and reusable across the thousand other places you've typed that same password. An SSH key pair (generate one with ssh-keygen -t ed25519) isn't any of those things. Copy your public key to the server with ssh-copy-id, confirm key-based login actually works, then set PasswordAuthentication no in /etc/ssh/sshd_config and restart the service. Protect the private key itself with a passphrase, a stolen unencrypted key is just as bad as a stolen password.

Root Login Off, Named Users Only

Set PermitRootLogin no so nobody, including you on a bad day, can log in directly as root over the network. Use a named account with sudo for anything that needs elevated privileges instead, that gives you an audit trail of who did what. If you want to go further, AllowUsers in sshd_config restricts SSH access to an explicit list of accounts, so a new user added to the box later doesn't automatically inherit remote access.

Rate-Limit and Actually Watch the Attempts

Even with keys-only auth, your box is still fielding constant automated login attempts, they just all fail now instead of eventually succeeding. Run fail2ban (or sshguard) to automatically ban IPs after a handful of failed attempts, it keeps your logs readable and your CPU from babysitting a flood of noise. Glance at /var/log/auth.log or journalctl -u ssh occasionally, not out of paranoia, just to keep a rough sense of what normal looks like on your own box.

The Extra Mile: 2FA and Bastion Hosts

For anything higher-value, add a second factor on top of your key with the google-authenticator PAM module, so a compromised key alone still isn't enough to get in. On a home network with multiple machines, consider routing all SSH access through one hardened bastion host instead of exposing every box individually, fewer exposed doors means fewer things to keep patched and watched. Neither of these is required to be reasonably safe, but both are worth knowing exist before you decide you don't need them.