The first 10 minutes on a new Linux server
A fresh VPS starts receiving brute-force login attempts within minutes of booting — before you've even finished reading the welcome email. None of it is personal; bots scan the entire IPv4 space constantly. The checklist below is the settling-in routine we've used for years, in the order that matters. Commands are for Debian/Ubuntu; the ideas transfer everywhere.
1. Log in, update everything
ssh root@203.0.113.10 apt update && apt upgrade -y
Provider images are often weeks old. Patch first, reboot if the kernel was
updated (reboot — it takes seconds and you'll know your server comes
back up, which is worth learning now rather than mid-crisis).
2. Create your everyday user
adduser rob usermod -aG sudo rob
Day-to-day work happens as this user; sudo covers the admin moments.
Working as root permanently means every typo runs with full privileges and every
log line says "root did it".
3. SSH keys, then close the password door
If you don't have a keypair yet, generate one on your own machine (see our SSH clients guide for the Windows angle):
# on your laptop ssh-keygen -t ed25519 ssh-copy-id rob@203.0.113.10 # confirm key login works BEFORE the next step ssh rob@203.0.113.10
Now harden the SSH daemon. Edit /etc/ssh/sshd_config (or better, a
drop-in file in /etc/ssh/sshd_config.d/):
PasswordAuthentication no PermitRootLogin no KbdInteractiveAuthentication no
sudo systemctl restart ssh
Keep your current session open while you test a fresh connection in a second terminal — a locked-out SSH session with a working one still attached is an inconvenience; without one it's a trip to the provider's rescue console. Those three lines eliminate the entire password-guessing class of attack: no password to guess, no root account to aim at.
4. Firewall: deny by default
sudo ufw allow OpenSSH sudo ufw enable sudo ufw status verbose
That's a complete firewall policy for a new box: SSH in, nothing else, all
outbound allowed. Add ports as you actually deploy things
(sudo ufw allow 80,443/tcp when the web server arrives). Anything you
haven't explicitly opened — a database bound to the wrong interface, some tool's
debug port — is unreachable, which converts configuration slips from incidents into
non-events.
5. Unattended security updates
sudo apt install unattended-upgrades sudo dpkg-reconfigure -plow unattended-upgrades
Security patches now install themselves. On a personal server the tiny risk of an automatic update misbehaving is vastly outweighed by the certainty that you won't be reading security advisories on holiday.
6. fail2ban: ban the door-rattlers
sudo apt install fail2ban sudo systemctl enable --now fail2ban
Out of the box it watches the SSH log and temporarily bans IPs that keep failing.
With passwords already disabled it's belt-and-braces, but it keeps logs readable and
cuts the background noise dramatically. Check its work later with
sudo fail2ban-client status sshd — the ban count is oddly
satisfying.
What we deliberately left out
- Changing the SSH port — mild log-noise reduction, zero real security; scanners check every port. Fine as a preference, not a defence.
- Port knocking, VPN-only SSH — legitimate for high-value targets, overkill for a first server, and each adds a way to lock yourself out.
- Disabling IPv6, kernel hardening flags, etc. — cargo-cult items copied between blog posts for a decade. The five steps above are the ones with real payoff.
Ten minutes, and the two attack surfaces that actually compromise small servers — guessable credentials and unpatched software — are closed. Now put something on it: our self-hosting starter guide is the natural next step.