How to Secure New VPS for First 10 Minutes

First 10 minutes na dem go decide how safe your server dey

New VPS no safe. From the moment e get public IP, scanners don dey try log in, and default image dey give dem big target: root often dey reachable, passwords often dey allowed, firewall no dey, and nothing dey patched on schedule. The good news be say you fit close all these gaps in about ten minutes with small number of commands. Na this runbook I dey use for every new server before I put anything on top am.

Follow am in order, because each step dey depend on the ones before am. Each step get im own guide, and link dey where e apply; this page na the fast path wey join everything together.

Minute 1: Update everything

Log in as root with the credentials wey your provider give you, then update the whole system before you do anything else:

apt update && apt upgrade -y

Unpatched server na the easiest target, so na this one you go do first. Once e finish, set automatic security updates so the system go dey patched without you needing to remember.

Minute 2: Create normal user wey get sudo

No continue dey work as root. Create user for yourself and give am sudo:

adduser matt
usermod -aG sudo matt

From this point, log in as this user and use sudo for admin tasks. If you dey run as root all the time, every mistake and every breach go happen with unlimited power. Na exactly wetin running as unprivileged user dey prevent.

Minute 4: Set up SSH keys

Password fit get guessed; keys no dey get guessed like that. For your own laptop, if you never get key before, create one:

ssh-keygen -t ed25519

Then copy the public half go the server:

ssh-copy-id matt@YOUR_SERVER

ssh-copy-id need password login to dey on for the new user; if e don already off, copy root's ~/.ssh/authorized_keys into /home/matt/.ssh/authorized_keys (wey matt own), or paste your public key into that file by hand.

The model behind this step, one key for each device, the permissions wey fit break key login, and how to revoke lost key, dey covered for SSH key management basics.

Log out and log back in as matt with the key, then confirm say e dey work before you touch the next step. If you lock SSH down before you fit enter with key, na so people dey lock themselves out. If that login come back with Permission denied (publickey), fix am now instead of falling back to password, because that one message fit mean five different faults, and the ssh -v output go tell you which one you actually get.

Minute 6: Turn off root login and passwords

Now wey your key dey work, close the two doors wey scanners dey depend on. Use a drop-in file so package upgrades no go overwrite am. Name am 00- so e go sort before 50-cloud-init.conf, wey Ubuntu cloud images ship with PasswordAuthentication yes; sshd dey keep the first value wey e read, so file wey sort later fit 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 wey sshd actually dey use, so drop-in wey lose no go deceive 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, dey for SSH hardening on a VPS.

Minute 8: On firewall

By default, block every inbound traffic, then allow only wetin you need. Allow SSH before you enable the firewall, or you go cut your own connection:

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

Add allow rules for any service wey you actually dey run, like 80/tcp and 443/tcp for website. If new SSH session stop to connect after this, read the error before you touch anything, because refusal mean sshd answer, while timeout usually mean firewall swallow the packet. Check say both IPv4 and IPv6 dey covered, because firewall wey only filter IPv4 go leave the IPv6 side wide open. The complete walkthrough dey for Firewalls 101 for VPS. These ufw commands assume say na Ubuntu or Debian; for Rocky or AlmaLinux box, the default-deny goal still dey the same, but the tool na firewalld, so follow the firewalld version of this step instead.

Minute 10: Make scanners slow with Fail2ban

Finally, add Fail2ban to remove addresses wey dey hammer your ports:

sudo apt install -y fail2ban

For Ubuntu 24.04, the default install dey protect SSH from the first boot. Since keys don already dey required, this one na extra protection wey reduce log noise and block repeat offenders, instead of being your main defence.

Your checklist

Na dis be the runbook. Use the generator below to tick each control and produce checklist wey match your setup, including the exact command for every step:

Go through am once for every new server, and the whole process go become muscle memory. Ten minutes now fit save you from the very bad afternoon wey follow after somebody don take over your server.

After you put the essentials in place, automatic security updates for Ubuntu go keep the server current without you logging in again. Every service wey you add on top still need its own security check, and the weak points dey change: for self-hosted password vault, the server no dey store plaintext, so the real risks of Vaultwarden na the admin token and the backup file.

FAQ

Wetin I suppose do first for new VPS?

Update the system with apt update && apt upgrade -y, then create normal user wey get sudo and stop to dey work as root. From there, set up SSH keys, disable root login and password authentication, enable default-deny firewall, and install Fail2ban. If you do dem for this order, each step go safe without locking you out.

How I fit avoid locking myself out while I dey harden SSH?

Set up and test your SSH key login before you disable passwords or root. Log out and log back in with the key to confirm say e dey work, and na then turn off PasswordAuthentication and PermitRootLogin. When you enable the firewall, allow port 22 before you run ufw enable. If you get locked out, your provider web console go let you enter again without SSH.

I really need all these things for small server?

Yes, because scanners no care how small your server be. Dem dey try every public IP the same way. The whole runbook dey take about ten minutes and e remove the easy attack paths: no root login, no password guessing, nothing exposed wey you no choose, and known bugs patched automatically.

Wetin be the one most important step?

Key-only SSH with root login disabled. Most attacks on fresh VPS na automated password guesses against root, and turning off both things make that whole attack category impossible. The firewall and Fail2ban then limit wetin dey exposed and slow down anything wey remain.

How I fit confirm say the server really dey locked down?

Check three things by hand before you trust am. Run sudo ss -tlnp and confirm say na only the ports wey you mean to open dey listen on public address, with no 0.0.0.0 or [::] service wey you forget. Run sudo ufw status verbose and confirm say the default incoming policy na deny and say both the plain and (v6) rules dey present. And always open second SSH session before you close the first one, so mistake for SSH configuration no go lock you out of the server. If all three look correct, the basic setup don dey in place.