Hardening a fresh Linux server: the first 20 minutes
A complete first-hour security checklist for a new Debian, Ubuntu or AlmaLinux VPS — SSH keys, firewall, automatic updates, fail2ban, and the checks that actually matter.
A newly deployed VPS is reachable from the entire internet within seconds, and the credential that came with it is a password. This guide is the first twenty minutes, in order, for Debian, Ubuntu or AlmaLinux. Do it before you install anything else — a compromised box cannot be trusted to host anything.
Minute 0–3 — SSH keys before anything else
Password login is the reason most fresh servers are compromised. Install your key before you disable anything, and confirm the key works before you close the session you are connected through.
- 01.On your local machine: ssh-keygen -t ed25519 -C 'vps'.
- 02.Copy the public key: ssh-copy-id root@YOUR_SERVER_IP.
- 03.Confirm it works: ssh root@YOUR_SERVER_IP with no password prompt.
- 04.Only then disable password authentication.
Note · Never disable password login until key login is verified in a second terminal. A misconfigured sshd on your only server is a lockout, not a security improvement.
Minute 3–6 — disable password login properly
Edit /etc/ssh/sshd_config and set three values. Reload rather than restart so a bad config does not kill the session.
- ▹PermitRootLogin prohibit-password — root login by key is fine, by password is not.
- ▹PasswordAuthentication no — keys only.
- ▹PubkeyAuthentication yes — make sure the key path is actually enabled.
Run systemctl reload sshd, open a new terminal and confirm the key works. Then test a second key login from a separate session before closing anything. The SSH hardening guide has the exact config and the verification order.
Minute 6–9 — firewall
Default-deny inbound, allow what you actually need. ufw on Debian/Ubuntu, firewalld on AlmaLinux.
- 01.Allow SSH first: ufw allow 22/tcp — always first, or you lock yourself out.
- 02.Allow only the ports your services need: 80 for HTTP, 443 for HTTPS.
- 03.Set the default: ufw default deny incoming, ufw default allow outgoing.
- 04.Enable: ufw enable.
Note · If you run fail2ban, do not add a rule blocking port 22 without a jail that respects your own IP, or you can ban yourself out.
Minute 9–12 — automatic security updates
Unpatched kernel and library vulnerabilities are the most common real-world entry point. Enable unattended upgrades so patching does not depend on you remembering.
- ▹Debian/Ubuntu: install unattended-upgrades and enable security updates.
- ▹AlmaLinux: enable dnf-automatic-timers.
- ▹Reboot automatically when the kernel requires it, or set a reminder to do it manually.
Minute 12–15 — fail2ban
With keys-only SSH, fail2ban matters less, but it is cheap insurance against credential stuffing against any remaining password surface. Install it, enable the ssh jail, and set a short findtime and bantime.
Minute 15–18 — verify what is exposed
Do not assume. Check what is actually listening and compare it against what you intended.
- 01.ss -tulpn — every listening socket with its owning process.
- 02.From your machine: nmap -Pn YOUR_SERVER_IP — the external view.
- 03.Anything listening on 0.0.0.0 that you did not plan is a decision to make now, not later.
Minute 18–20 — the rest of the checklist
- ▹Change nothing about the hostname yet; make sure your monitoring and reverse proxy DNS resolve correctly first.
- ▹Set the timezone and enable NTP so logs are meaningful.
- ▹Install restic or your backup of choice and schedule it — before you have data you care about.
- ▹Add a monitoring check for the service you are about to deploy, not just for the server being up.
What this does not cover
Twenty minutes of hardening gives you a server that will not fall to an automated scan. It does not give you an immutable system, a vetted application stack, or an incident response plan. Those are ongoing work — but the first twenty minutes are what keep a fresh box from becoming someone else's.
FAQ
QDo I need fail2ban if I use keys only?
ALess urgently, but still worth it. Keys make brute force futile, and fail2ban reduces noise and covers any service that still accepts passwords.
QShould I disable root login entirely?
ANot necessarily. Root-by-key is acceptable; root-by-password is what matters. Disabling root entirely and using a sudo user adds a step for little security gain if your key is protected.
QWhat order do I do this in?
ASSH keys first, verify, then disable passwords, then firewall, then updates, then verify exposure. Each step assumes the previous one works.