wetin I must do for new VPS first 10 mins

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

New VPS no safe at all. As soon as e get public IP, scanners go start to try log in, and default image dey give dem easy target: root dey easy to reach, password dey allowed, no firewall, and nothing dey patch for schedule. Good news na say to close all those things go take about ten minutes and small commands. Na this runbook I dey use for every new server before I put anything for am.

Follow am step-by-step because the steps dey build on each other. Every step get its own guide, wey dey link as you dey go; this page na the fast path wey tie dem together.

Minute 1: Update everything

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

apt update && apt upgrade -y

Box wey no get patch na the easiest target, so this one na first thing. Once e finish, set up automatic security updates so e go stay patched without you to dey remember.

Minute 2: Create a normal user with sudo

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

adduser matt
usermod -aG sudo matt

From here, you go log in as this user and use sudo for admin tasks. To work as root all the time mean say every mistake and every compromise go happen with unlimited power, and na wetin running as an unprivileged user dey try prevent.

Minute 4: Set up SSH keys

Scanners dey guess password, but dem no fit guess keys. For your own laptop, if you no get key yet, create one:

ssh-keygen -t ed25519

Then copy the public half to 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 for this step—one key per device, the permissions wey dey break key login, and how to revoke lost key—dey inside SSH key management basics.

Log out and log back in as matt using the key, and make sure e work before you touch the next step. To lock down SSH before you fit enter with key na how people dey lock themselves out.

Minute 6: Turn off root login and passwords

Now wey your key don work, close the two doors wey scanners dey use. 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 dey come with PasswordAuthentication yes; sshd dey keep the first value wey e read, so file wey dey sort later go 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 dey actually use, so say one losing drop-in no go fool you:

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

With passwords off and root login gone, the constant brute-force traffic wey dey hit your server no go fit succeed. The full treatment, including optional port change, dey inside SSH hardening on a VPS.

Minute 8: Turn on the firewall

Default-deny everything inbound, then allow only wetin you need. Allow SSH before you enable 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 dey run, like 80/tcp and 443/tcp for website. Check say both IPv4 and IPv6 dey covered, because firewall wey only filter IPv4 dey leave IPv6 side wide open. The full walkthrough dey Firewalls 101 on a VPS.

Minute 10: Slow the scanners with Fail2ban

Finally, add Fail2ban to kick out the addresses wey dey hammer your ports:

sudo apt install -y fail2ban

For Ubuntu 24.04, the stock install dey protect SSH from first boot. Since you don already require keys, this one na backstop wey dey reduce log noise and block repeat offenders, rather than your main defence.

Your checklist

Na that be the runbook. Use the generator below to tick off each control and produce a personalised checklist wey you fit keep with the server, including the exact command for each step:

Do am once for every new server and the whole thing go become muscle memory. Ten minutes now go save you from the very bad afternoon wey dey follow when server get owned.

Once the essentials don set, automatic security updates on Ubuntu go keep the server current without you to dey log back in.

FAQ

What should I do first on a new VPS?

Update the system with apt update && apt upgrade -y, then create 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. To do dem in that order mean say each step safe to do without you to lock 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 log back in with the key to confirm e work, and only then turn off PasswordAuthentication and PermitRootLogin. When you enable the firewall, allow port 22 before you run ufw enable. If you lock yourself out, your provider's web console go help you enter without SSH.

Do I really need all of these on a 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 dey remove the easy paths: no root login, no password guessing, nothing exposed wey you no choose, and known bugs dey patch automatically.

What is the single most important step?

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

How do I confirm the server is actually locked down?

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