A fresh VPS gets scanned within minutes of getting a public IP. Bots probe port 22 constantly, looking for default passwords and known weak configs. Do these steps before you install anything else — not after your app is running.

1. Create a non-root user

Never run day-to-day work as root. As root, create a user and give it sudo access:

adduser deploy
usermod -aG sudo deploy

Test that it works — open a second terminal and log in as deploy before you close your root session. If sudo is misconfigured, you want to find out while root still works, not after you’ve locked yourself out.

2. Set up SSH keys, then kill password auth

On your local machine, generate a key if you don’t have one, then copy it over:

ssh-copy-id deploy@your-server-ip

Confirm you can log in as deploy with the key and no password. Then edit /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin no

Restart SSH: sudo systemctl restart sshd. From now on, a stolen password is useless against this box — the only way in is the key.

3. Enable the firewall

Install UFW if it’s not already there, allow SSH first (skip this and you’ll lock yourself out the moment you enable it), then lock down everything else:

sudo ufw allow OpenSSH
sudo ufw enable

Add web ports as you need them (sudo ufw allow 80,443/tcp), but don’t open anything you’re not actively using yet.

4. Install fail2ban

UFW stops unauthorized ports; it doesn’t stop someone hammering the ports you did open. fail2ban watches logs and temporarily bans IPs after repeated failed login attempts:

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

The default SSH jail is enabled out of the box on most distros — verify with sudo fail2ban-client status sshd.

5. Turn on unattended upgrades

Security patches you don’t install don’t protect you. On Ubuntu/Debian:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

This applies security patches automatically without you needing to remember a weekly apt upgrade. It won’t reboot the box for a kernel update unless you also configure that — decide if you want automatic reboots or just want to be reminded.

6. Set the timezone and check the clock

Sounds trivial, wastes hours later. TLS certificate validation, log timestamps, and cron schedules all depend on correct time:

sudo timedatectl set-timezone UTC
timedatectl

Use UTC on the server regardless of where you are — it makes correlating logs across multiple servers and services far less error-prone.

What this checklist deliberately skips

This is the first-hour list, not the whole job. It doesn’t cover disk encryption, intrusion detection, log shipping to an external host, or a WAF — those are real, but they’re not what’s getting your box compromised in week one. Password-auth SSH left on, no firewall, and a root user with a guessable password are what actually get exploited, usually by automated scanners rather than a targeted attacker.

The gotcha

Do steps 1 and 2 in order, and verify each one in a fresh session before moving on. The most common way people lock themselves out of a fresh VPS isn’t a firewall mistake — it’s disabling password auth before confirming the SSH key actually works, then discovering the only account left is root, which you just told SSH to reject. If that happens, you’re back to your provider’s web console or rescue mode to fix it. Five minutes of verification now saves that entirely.