First 10 minutes on a new VPS

The first 10 minutes decide how safe your server is

A brand-new VPS is not safe. From the moment it has a public IP, scanners are trying to log in, and the default image gives them a large target: root often reachable, passwords often allowed, no firewall, nothing patched on a schedule. The good news is that closing all of that takes about ten minutes and a handful of commands. This is the runbook I run on every new server before I put anything on it.

Work through it in order, because the steps build on each other. Each one has its own guide, linked as you go; this page is the fast path that ties them together.

Minute 1: Update everything

Log in as root with the credentials your provider gave you, and bring the system fully up to date before anything else:

apt update && apt upgrade -y

An unpatched box is the easiest target there is, so this comes first. Once it finishes, set up automatic security updates so it stays patched without you having to remember.

Minute 2: Create a normal user with sudo

Do not keep working as root. Create a user for yourself and give it sudo:

adduser matt
usermod -aG sudo matt

From here you log in as this user and use sudo for admin tasks. Running as root all the time means every mistake and every compromise happens with unlimited power, which is exactly what running as an unprivileged user exists to prevent.

Minute 4: Set up SSH keys

Passwords get guessed; keys do not. On your own laptop, if you do not already have a key, create one:

ssh-keygen -t ed25519

Then copy the public half to the server:

ssh-copy-id matt@YOUR_SERVER

ssh-copy-id needs password login to be on for the new user; if it is already off, copy root's ~/.ssh/authorized_keys into /home/matt/.ssh/authorized_keys (owned by matt), or paste your public key into that file by hand.

Log out and back in as matt using the key, and confirm it works before you touch the next step. Locking down SSH before you can get in with a key is how people lock themselves out.

Minute 6: Turn off root login and passwords

Now that your key works, close the two doors the scanners rely on. Use a drop-in file so package upgrades do not overwrite it. Name it 00- so it sorts before 50-cloud-init.conf, which Ubuntu cloud images ship with PasswordAuthentication yes; sshd keeps the first value it reads, so a later-sorting file would silently lose:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Then reload SSH:

sudo systemctl restart ssh

Then check the settings sshd actually uses, so a losing drop-in cannot fool you:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

With passwords off and root login gone, the constant brute-force traffic against your server simply cannot succeed. The full treatment, including an optional port change, is in SSH hardening on a VPS.

Minute 8: Turn on the firewall

Default-deny everything inbound, then allow only what you need. Allow SSH before you enable it, or you cut your own connection:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Add allow rules for any service you actually run, such as 80/tcp and 443/tcp for a website. Check that both IPv4 and IPv6 are covered, because a firewall which only filters IPv4 leaves the IPv6 side wide open. The full walkthrough is Firewalls 101 on a VPS.

Minute 10: Slow the scanners with Fail2ban

Finally, add Fail2ban to evict the addresses that hammer your ports:

sudo apt install -y fail2ban

On Ubuntu 24.04 the stock install protects SSH from first boot. With keys already required, this is a backstop that trims log noise and blocks repeat offenders, rather than your main defence.

Your checklist

That is the runbook. Use the generator below to tick off each control and produce a personalised checklist you can keep with the server, including the exact command for each step:

Work down it once per new server and the whole thing becomes muscle memory. Ten minutes now saves you the very bad afternoon that follows a server getting owned.

Once the essentials are in place, automatic security updates on Ubuntu keep the server current without you logging back in.

FAQ

What should I do first on a new VPS?

Update the system with apt update && apt upgrade -y, then create a normal user with sudo and stop working as root. From there, set up SSH keys, disable root login and password authentication, enable a default-deny firewall, and install Fail2ban. Doing them in that order means each step is safe to take without locking yourself out.

How do I avoid locking myself out while hardening SSH?

Set up and test your SSH key login before you disable passwords or root. Log out and back in with the key to confirm it works, and only then turn off PasswordAuthentication and PermitRootLogin. When you enable the firewall, allow port 22 before running ufw enable. If you do get locked out, your provider's web console gets you back in without SSH.

Do I really need all of these on a small server?

Yes, because the scanners do not care how small your server is. They try every public IP the same way. The whole runbook takes about ten minutes and removes the easy paths: no root login, no password guessing, nothing exposed you did not choose, and known bugs patched automatically.

What is the single most important step?

Key-only SSH with root login disabled. Most attacks on a fresh VPS are automated password guesses against root, and turning both off makes that entire category of attack impossible. The firewall and Fail2ban then limit what is exposed and slow anything that remains.

How do I confirm the server is actually locked down?

Check three things by hand before you trust it. Run sudo ss -tlnp and confirm only the ports you meant to open are listening on a public address, with no 0.0.0.0 or [::] service you had forgotten about. Run sudo ufw status verbose and confirm the default incoming policy is deny and that both the plain and the (v6) rules are present. And always open a second SSH session before you close the first, so a mistake in the SSH configuration cannot lock you out of the server. If all three look right, the basics are in place.