{"id":62,"date":"2026-08-01T12:24:24","date_gmt":"2026-08-01T09:24:24","guid":{"rendered":"https:\/\/john-nessime.com\/blog\/?p=62"},"modified":"2026-08-01T12:24:32","modified_gmt":"2026-08-01T09:24:32","slug":"vps-hardening-checklist","status":"publish","type":"post","link":"https:\/\/john-nessime.com\/blog\/linux\/vps-hardening-checklist\/","title":{"rendered":"You Probably Didn’t Harden That Server: A VPS Setup and Hardening Checklist That Verifies Itself"},"content":{"rendered":"\n

You spun up a new box, worked through a hardening guide, set PasswordAuthentication no<\/code>, restarted SSH, and moved on. Six months later you are reading auth logs for an unrelated reason and there it is: successful password logins. Not attempts. Logins.<\/p>\n\n\n\n

The line you wrote was real. The file was saved. What you did not know is that your distro puts an Include \/etc\/ssh\/sshd_config.d\/*.conf<\/code> near the top of sshd_config<\/code>, that sshd uses the first<\/em> value it finds for any given keyword, and that your cloud provider’s image dropped a 50-cloud-init.conf<\/code> in that directory setting PasswordAuthentication yes<\/code>. It sorts earlier. It wins. Your line at the bottom of the main file was never reached.<\/p>\n\n\n\n

You never noticed because you log in with a key anyway. Nothing broke. The control just was not there.<\/p>\n\n\n\n

That is the thing most guides get wrong, and it is the idea this VPS hardening checklist<\/strong> is built around: a hardening step is not done when you have edited the file. It is done when you have checked the effective configuration and seen the value you expected. Everything below comes with the command that proves it.<\/p>\n\n\n\n

This covers the order to do things in so you do not lock yourself out, SSH keys and config, the firewall, automatic updates, fail2ban and whether it is worth it, the unglamorous things that matter more than any of it, and what I would skip.<\/p>\n\n\n\n

Before you touch anything<\/h2>\n\n\n\n

Two minutes of preparation that saves an evening.<\/p>\n\n\n\n

Find your provider’s console before you need it.<\/strong> Whether you are on InterServer, Hetzner, DigitalOcean or anything else, there is a web-based serial or VNC console that works when SSH does not. Open it now, log in as root, and confirm it works. This is your parachute. If you are going to lock yourself out, you want to already know where it is.<\/p>\n\n\n\n

Never close the session you are working in.<\/strong> Every SSH change gets tested from a second terminal while the first one stays open. If the new settings are broken, the old session is still authenticated and you can undo them. Close it too early and your only route back in is the console.<\/p>\n\n\n\n

Then update the system, because everything else assumes current packages:<\/p>\n\n\n\n

sudo apt update && sudo apt upgrade -y\nsudo reboot   # if a kernel update landed<\/code><\/pre>\n\n\n\n
1. A real user, and keys instead of passwords<\/h2>\n\n\n\n
Generate the key on your own machine, not on the server. A private key that has been on a server is not a private key any more.<\/p>\n\n\n\n
# On your laptop. ed25519 is the sane default: short keys,\n# fast verification, no parameter choices to get wrong.\nssh-keygen -t ed25519 -C \"deploy@my-laptop\"<\/code><\/pre>\n\n\n\n
# On the server, as root.\nadduser deploy\nusermod -aG sudo deploy        # 'wheel' instead of 'sudo' on RHEL-family\n\n# Back on your laptop. ssh-copy-id appends to authorized_keys\n# and sets the permissions correctly, which is the part people\n# get wrong when they paste the key by hand.\nssh-copy-id deploy@203.0.113.10<\/code><\/pre>\n\n\n\n
Now open a second terminal and confirm ssh deploy@203.0.113.10<\/code> works, and that sudo -v<\/code> works once you are in. Only then move on. If either fails, fix it before you disable anything, because in a minute you will be removing the fallback.<\/p>\n\n\n\n
2. SSH config, and why your edit might do nothing<\/h2>\n\n\n\n
This is the section that actually matters. Two mechanisms silently override what you write.<\/p>\n\n\n\n
Drop-in files and first-match-wins<\/h3>\n\n\n\n
Modern OpenSSH packages ship an Include<\/code> line near the top of \/etc\/ssh\/sshd_config<\/code>, which pulls in every .conf<\/code> file from \/etc\/ssh\/sshd_config.d\/<\/code> in alphabetical order, before the rest of the main file is read. Combine that with sshd’s rule that the first value found for a keyword wins, and the consequence is specific: your drop-in has to sort earlier than the vendor’s, not later.<\/strong><\/p>\n\n\n\n
Most guides tell you to name it 99-something.conf<\/code>, which is the convention almost everywhere else in Linux and exactly backwards here.<\/p>\n\n\n\n
# \/etc\/ssh\/sshd_config.d\/00-hardening.conf\n# Sorts before 50-cloud-init.conf, so these values are seen first.\n\nPermitRootLogin no\nPasswordAuthentication no\nKbdInteractiveAuthentication no\nPubkeyAuthentication yes\n\n# Optional: restrict to the accounts that should have shell access.\nAllowUsers deploy<\/code><\/pre>\n\n\n\n
A note on KbdInteractiveAuthentication<\/code>: older guides and older OpenSSH call this ChallengeResponseAuthentication<\/code>. Setting only PasswordAuthentication no<\/code> can still leave a keyboard-interactive path open on some configurations, which is why both are here.<\/p>\n\n\n\n
Now the part nobody does. Validate the syntax, then read the effective config:<\/p>\n\n\n\n
# Syntax check. Prints nothing if the config is valid.\n# Run this BEFORE restarting, always.\nsudo sshd -t\n\n# Dump the effective configuration with every include resolved.\n# This is the only output that tells you the truth.\nsudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|kbdinteractive|pubkeyauth'<\/code><\/pre>\n\n\n\n
If passwordauthentication yes<\/code> comes back, your file lost to something else in that directory. Look at what is in there with ls \/etc\/ssh\/sshd_config.d\/<\/code> and either rename yours to sort earlier or edit the offending file directly.<\/p>\n\n\n\n
Socket activation, and the port that will not change<\/h3>\n\n\n\n
The second trap. On several current distro releases, SSH is started by systemd socket activation rather than as a persistent service: ssh.socket<\/code> holds the listening port and starts sshd<\/code> only when a connection arrives. On those systems the Port<\/code> and ListenAddress<\/code> directives in sshd_config<\/code> may be ignored entirely, because systemd owns the socket.<\/p>\n\n\n\n
People change the port, restart the service, see no error, and assume it worked. Check what is actually bound:<\/p>\n\n\n\n
# -t TCP, -l listening, -n numeric, -p show the owning process\nsudo ss -tlnp<\/code><\/pre>\n\n\n\n
If you genuinely want a different port on a socket-activated system, override the socket unit with a proper drop-in rather than editing files under \/lib\/systemd\/system\/<\/code>, which a package update will overwrite:<\/p>\n\n\n\n
sudo systemctl edit ssh.socket<\/code><\/pre>\n\n\n\n
# In the editor that opens:\n[Socket]\n# The empty assignment clears the inherited value. Without it\n# you end up listening on both the old port and the new one.\nListenStream=\nListenStream=2222<\/code><\/pre>\n\n\n\n
sudo systemctl daemon-reload\nsudo systemctl restart ssh.socket\nsudo ss -tlnp        # confirm before you trust it<\/code><\/pre>\n\n\n\n
Honest assessment of port changes: this is not security. Anyone scanning your address finds an SSH daemon on a non-standard port in seconds. What it genuinely does is cut the volume of automated login noise in your logs by a large margin, which makes real events easier to see. That is a maintenance benefit, not a defence, and it is worth doing for that reason alone. Just do not count it as one of your controls.<\/p>\n\n\n\n
\n\n\n\n
3. Firewall, in the right order<\/h2>\n\n\n\n
The ordering here is the whole trick. Set the default policy and add your rules before<\/em> you enable the firewall. Enable first and you will drop your own connection with the policy that denies everything.<\/p>\n\n\n\n
sudo ufw default deny incoming\nsudo ufw default allow outgoing\n\n# Allow SSH BEFORE enabling. If you changed the port,\n# allow that port instead of the OpenSSH profile.\nsudo ufw allow OpenSSH\n# sudo ufw allow 2222\/tcp\n\nsudo ufw allow 80,443\/tcp\n\nsudo ufw enable\nsudo ufw status verbose<\/code><\/pre>\n\n\n\n
Read that status verbose<\/code> output rather than assuming. It shows the default policies and every rule, and it is the proof that this step is done.<\/p>\n\n\n\n
One thing worth knowing if you run containers: Docker writes its own rules directly into netfilter and bypasses ufw. A container published with -p 5432:5432<\/code> is reachable from the internet even though ufw says that port is denied. Bind container ports to 127.0.0.1<\/code> explicitly, or put the service behind a reverse proxy, and verify from outside the box with a port scan rather than trusting the firewall status.<\/p>\n\n\n\n
A stronger option worth considering: do not expose SSH to the internet at all. Put the server on a private overlay network with something like Tailscale or a WireGuard tunnel, bind sshd to that interface, and close port 22 to the world entirely. More setup, and it removes an entire class of problem rather than filtering it.<\/p>\n\n\n\n
4. Automatic security updates<\/h2>\n\n\n\n
Unpatched packages are a far more realistic route into your server than an SSH brute force. This is the highest-value item on the list and it takes two commands.<\/p>\n\n\n\n
sudo apt install unattended-upgrades\nsudo dpkg-reconfigure --priority=low unattended-upgrades\n\n# Verify. Note the binary is singular, the package is plural.\n# --dry-run makes no changes.\nsudo unattended-upgrade --dry-run --debug<\/code><\/pre>\n\n\n\n
By default this applies security updates only, which is the right scope. Enabling automatic reboots is a real trade-off: it closes kernel vulnerabilities without you doing anything, and it will restart your server at whatever hour you configure. On a single web server with a proper service startup order, I turn it on. On anything holding state that does not recover cleanly from a hard restart, I leave it off and patch by hand.<\/p>\n\n\n\n
5. fail2ban, and what it is actually for<\/h2>\n\n\n\n
Install it, but be clear about the role. Once password authentication is off and root login is disabled, a brute force against sshd cannot succeed. There is no password to guess. fail2ban is not what is keeping those attackers out; your key-only config is.<\/p>\n\n\n\n
What it does earn its place for is reducing log noise and CPU spent on connection handling, and protecting the services where credentials do<\/em> exist: a mail server, a web application login form, an FTP daemon.<\/p>\n\n\n\n
sudo apt install fail2ban\n\n# Do not edit jail.conf; it gets replaced on upgrade.\nsudo cp \/etc\/fail2ban\/jail.conf \/etc\/fail2ban\/jail.local\n\nsudo systemctl enable --now fail2ban\nsudo systemctl status fail2ban\nsudo fail2ban-client status sshd<\/code><\/pre>\n\n\n\n
Check that status<\/code> output properly. fail2ban has shipped in states where the service fails to start on a given distro release because the packaged version does not match the system Python, and it fails loudly in the journal and silently everywhere else. A stopped fail2ban looks exactly like a working one from the outside. If it is not running, journalctl -u fail2ban<\/code> will tell you why.<\/p>\n\n\n\n
Set ignoreip<\/code> in jail.local<\/code> to include your office or home address. Banning yourself is a rite of passage but it is avoidable.<\/p>\n\n\n\n
\n\n\n\n
6. The boring items that matter more than the exciting ones<\/h2>\n\n\n\n
Nobody writes blog posts about these, and they cause more real outages than any of the above.<\/p>\n\n\n\n
Provider account security<\/h3>\n\n\n\n
Turn on two-factor authentication in your hosting control panel and your domain registrar. Someone with your provider login does not need to defeat sshd; they can reset the root password from the console or attach your disk to a machine they control. This is the weakest link on most setups and it takes two minutes.<\/p>\n\n\n\n
Time and timezone<\/h3>\n\n\n\n
sudo timedatectl set-timezone UTC\ntimedatectl status       # look for \"System clock synchronized: yes\"<\/code><\/pre>\n\n\n\n
UTC on servers, always. Correlating logs across machines in different local times, one of which observes daylight saving, is a genuinely miserable way to spend an incident.<\/p>\n\n\n\n
Swap on small instances<\/h3>\n\n\n\n
# A little swap stops the OOM killer choosing your database\n# during a traffic spike. It is not a substitute for RAM.\nsudo fallocate -l 2G \/swapfile\nsudo chmod 600 \/swapfile\nsudo mkswap \/swapfile\nsudo swapon \/swapfile\necho '\/swapfile none swap sw 0 0' | sudo tee -a \/etc\/fstab\nfree -h<\/code><\/pre>\n\n\n\n
Backups that leave the machine<\/h3>\n\n\n\n
Your provider’s snapshots live in the same account as the server. If that account is compromised, or you delete the wrong thing, they go with it. A snapshot is a rollback mechanism, not a backup.<\/p>\n\n\n\n
Get database dumps and application data onto storage under a different set of credentials, on a schedule, and then do the part everyone skips: restore one. A backup you have never restored is a hypothesis. Point a dead man’s switch service at the backup job so you find out when it stops running, rather than the day you need it.<\/p>\n\n\n\n
Knowing the box is alive<\/h3>\n\n\n\n
At minimum, an external uptime check that alerts you. Better, node metrics into Prometheus with Grafana dashboards, or a hosted equivalent. Disk filling up is the single most common way a small VPS falls over, and it is completely predictable if anything is watching the graph.<\/p>\n\n\n\n
What I would skip<\/h2>\n\n\n\n
Not everything in the long hardening guides earns its cost on a single web server.<\/p>\n\n\n\n