How to secure a new VPS: the first ten minutes

A new server is at its most exposed the moment it gets an IP address. Automated scanners sweep the entire IPv4 space continuously, so the first login attempts against a box deployed a minute ago usually arrive before you have finished reading its welcome message. None of that is targeted at you — it is background radiation, and it is why an unhardened server with a password on root is compromised on a timescale of hours rather than months. The good news is that closing it down is short work: ten minutes of ordered steps removes essentially all of the opportunistic risk. This guide covers that checklist, the order that keeps you from locking yourself out, and one thing most hardening tutorials never mention — the personal details a default setup quietly writes onto a machine you rented specifically so it would not be linked to you.

What hardening actually protects you from

Hardening is worth doing precisely because its benefits are narrow and real. Being clear about the boundary keeps you from a false sense of safety in the areas it does not touch.

• It removes the opportunistic attacker entirely. Credential-stuffing bots, SSH brute force and scans for exposed admin panels all fail against keys-only authentication and a default-deny firewall.
• It limits the blast radius when something you run has a flaw. A service bound to localhost behind a closed port cannot be reached by a stranger even on the day its CVE is published.
• It reduces what a mistake costs. Unprivileged users, separate keys and automatic patching mean a single bad decision does not hand over the whole machine.
• It does not hide the server from your host. Anyone with access to the hypervisor can in principle read a running machine's memory — a question about who you rent from, not about your firewall rules.
• It does not make you anonymous. Hardening protects the box; whether the box is attached to your name is decided at signup and at payment, long before you first log in.

That last distinction is the one people get backwards. A perfectly hardened server bought with a credit card in your legal name is still a server in your legal name. The two layers are complementary: no-KYC hosting and a crypto-funded balance decide who the machine belongs to on paper, and the ten minutes below decide who can get into it.

The order that stops you locking yourself out

Almost every hardening horror story is the same story: someone disabled password authentication before confirming that their key worked, or enabled a firewall whose rules did not include SSH, and locked themselves out of a machine they can no longer reach. The sequence exists to make that impossible. Install the key first and prove it works in a second window. Only then turn passwords off. Add the firewall rule for SSH before enabling the firewall, never after.

It is also worth knowing what your recovery path is before you need it. A VPS you can only reach over SSH has exactly one door, so the console in your provider dashboard is the fallback that turns a lockout into an inconvenience rather than a rebuild. Check that you can open it while everything still works.

Step by step: the first ten minutes on a new box

1. 01Update the package index and installed packagesA fresh image is a snapshot from whenever it was built. Bringing it current is the single highest-value action on the list, and it takes under a minute.
2. 02Create an unprivileged user with sudoWorking as root all the time means every typo and every process runs with full authority. Make a normal user, add it to the sudo or wheel group, and use that.
3. 03Copy your public key to that userGenerate an ed25519 key on your own machine if you do not have one, then push the public half with ssh-copy-id. The private key never leaves your laptop.
4. 04Open a second terminal and confirm key login worksDo not skip this. Log in as the new user with the key, in a new window, before changing anything about authentication.
5. 05Disable password authentication and root loginSet PasswordAuthentication no and PermitRootLogin prohibit-password, then reload sshd. Brute force against the box now has nothing to guess.
6. 06Enable a default-deny firewall with SSH allowedDeny all inbound, allow your SSH port, then enable it. Add the ports your own services need afterwards, one at a time.
7. 07Turn on automatic security updatesunattended-upgrades on Debian and Ubuntu, dnf-automatic on the RHEL family. This is what keeps the machine safe in month six when you have stopped paying attention.
8. 08List what is listening and close what should not beOne ss -tulpn tells you every open socket. Anything you did not put there deliberately should be removed or bound to localhost.

SSH: keys only, and the settings that matter

Public-key authentication is the whole of SSH hardening. Once passwords are off, an attacker needs a private key they do not have, and no amount of guessing produces one. Generate ed25519 keys — they are short, fast, and the modern default — and give the key a passphrase so a stolen laptop is not a stolen server. Everything else in sshd_config is refinement on top of that one decision.

• PasswordAuthentication no — the setting that ends brute force. Verify your key works first, in a second session.
• PermitRootLogin prohibit-password — root can still be reached by key for recovery, but never by password. Set it to no once your sudo user is proven.
• AllowUsers or AllowGroups — an explicit allowlist of who may log in at all, so a service account created by some package can never be an SSH entry point.
• KbdInteractiveAuthentication no — closes the other interactive path that can quietly re-enable password prompts on some distributions.
• A second key for a second device, rather than copying one private key around. Losing a phone should mean removing one line from authorized_keys, not rotating everything.
• Moving SSH off port 22 cuts your log volume dramatically, but treat it as noise reduction rather than security — it changes nothing for anyone actually looking at your IP.

If you want to go further than keys, the strongest arrangement is not to expose SSH publicly at all: put the machine behind a WireGuard tunnel and firewall port 22 so it only accepts connections from the tunnel address. That turns your SSH daemon into something the internet cannot see, which is a better outcome than any amount of configuration hardening on an exposed one.

The firewall: default deny, then open exactly what you use

A firewall is only meaningful if its default is to refuse. Allowing everything and then blocking known-bad ports is backwards: you end up protecting against the services you remembered and exposing the ones you forgot. Deny all inbound traffic, permit outbound, and then open individual ports as you deploy the things that need them. Modern Linux uses nftables underneath, and ufw or firewalld are perfectly good front ends for it — the tool matters much less than the default.

• Allow SSH before you enable the firewall, not after. This is the second most common way to lock yourself out.
• Open only the ports a service genuinely needs from outside. A web server wants 80 and 443; a database almost never wants anything.
• Bind local-only services to 127.0.0.1 rather than 0.0.0.0. A closed port and a service that never listens publicly are two independent protections, and you want both.
• Write IPv6 rules as well as IPv4. A rule set that covers only v4 on a dual-stacked box leaves the same service wide open on its v6 address.
• Restrict management ports by source address where you can. If administration always comes from one VPN endpoint, say so in the rule.
• Re-read the rules after adding a service. Ports opened for something you have since removed are the quiet accumulation that undoes a clean start.

Some workloads invert the logic and need a wide-open port on purpose — a Tor relay has to accept connections from anywhere, and a Bitcoin full node only serves peers if 8333 is reachable. That is fine. The rule is not "open nothing", it is "open deliberately", and a service designed to be public is a deliberate choice.

fail2ban, and why it matters less than you think

fail2ban watches your logs and bans addresses that fail authentication repeatedly. It is genuinely useful, but it is worth being honest about what it does once you have already disabled password authentication: at that point nobody can succeed by guessing, so fail2ban is no longer preventing a break-in. What it prevents is thousands of pointless log lines a day, the CPU those connection attempts consume, and the risk that a real event is buried in noise you stopped reading months ago.

That is still worth ten seconds of setup, and it becomes genuinely protective the moment you run something that does accept a password — a web application login, a mail server, a control panel. Point it at those logs rather than only at sshd. Set the ban window in hours rather than minutes, and add your own address to the ignore list so a fat-fingered password does not lock you out of your own machine.

Updates you do not have to remember

The realistic threat to a well-configured server is not someone defeating your SSH keys. It is a vulnerability published for something you installed and forgot, exploited by a scanner three days later while you were doing other things. Automatic security updates are the answer, and on Debian or Ubuntu that is unattended-upgrades configured to install the security pocket; on Fedora, Rocky or Alma it is dnf-automatic. Turn it on during the first ten minutes and the machine keeps patching itself long after your attention has moved elsewhere.

Kernel and libc updates are the exception that still needs you: they only take effect after a restart, so a server that has been up for four hundred days is almost certainly running code that was patched on disk a year ago. Debian's needrestart will tell you which services are running against deleted libraries, and a scheduled reboot window — even a monthly one — is the difference between installed patches and applied ones. Anything you run should survive an unexpected reboot anyway; if it does not, that is a separate problem worth fixing.

The identity leaks a hardening checklist misses

This is the section that matters if you chose an offshore, no-KYC host on purpose. A standard hardening guide is written for a company server whose owner is a matter of public record, so it never asks what the default configuration writes down about you. On a machine you rented anonymously, several of those defaults quietly reattach your name to it.

• Your SSH public key carries a comment — by default your local username and your laptop's hostname, something like alex@alex-macbook — and that comment is stored verbatim in authorized_keys on the server. Set it with the -C flag when you generate the key, or edit the line after copying it.
• The server hostname you choose ends up in logs, in mail headers, in monitoring output and sometimes in service banners. A generic hostname reveals nothing; your name or your company's does.
• The system timezone. Cloud images default to UTC, which tells nobody anything. Setting it to your local zone narrows down where you are, and timestamps in every log then confirm your working hours.
• Git configuration copied onto the box, which carries the name and email address you commit under. So do shell history files, dotfiles synced from your workstation, and any credential cached during a hasty test.
• The email address you hand to Let's Encrypt during certificate issuance, which becomes part of a public record for that certificate. Use an address that is not tied to your identity.
• Web server version banners and X-Powered-By headers, plus any analytics, crash reporter or vendor monitoring agent that phones home from the machine with an account identifier attached.

It is worth keeping the layers straight. Hardening keeps strangers out of the machine. These details keep the machine from describing you to whoever is already looking at it. And the payment layer decides whether there was ever a name to find — a subject covered honestly in whether buying a VPS with Bitcoin is really anonymous, and taken further by topping up in Monero. Each layer fails on its own; together they hold.

Backups: the part hardening cannot do for you

No firewall rule protects against a deleted database, a failed disk or a configuration change that seemed reasonable at the time. Backups are the one control that recovers you from mistakes you make yourself, which is statistically the most likely way you will lose data on a well-secured machine. Encrypt them before they leave the server, keep at least one copy somewhere the server itself cannot reach, and set them to run on a schedule rather than when you remember.

That last point matters more than it sounds: a backup process the server can overwrite is a backup that anything with root on the server can destroy. Pushing encrypted archives to a separate storage server — or pulling them from it, so the credentials live off the machine being backed up — gives you a copy that survives the machine. And do the restore once, on purpose, while nothing is wrong. An untested backup is a hypothesis, not a safety net.

Mistakes that quietly undo the work

• Disabling password authentication before testing the key, then discovering the mistake from a laptop that can no longer log in.
• Enabling the firewall before allowing SSH — the same lockout, arrived at from the other direction.
• Writing IPv4 rules only, and leaving every service reachable on the box's IPv6 address.
• Hardening carefully on day one and then installing a control panel, a database and a monitoring stack that each open their own port without being asked.
• Running everything as root because it is one less sudo, so the first flaw in any of it is a full compromise.
• Treating fail2ban as a substitute for keys, which leaves a password-guessing game running that is merely slower.
• Assuming a rented server can be made private from its host by encrypting the disk — full-disk encryption protects a stolen drive, not a running machine.
• Never rebooting, so months of installed kernel patches sit on disk while the old kernel keeps running.

None of this is difficult and none of it takes long. Do it in order, prove each step from a second terminal before moving on, and the machine you deployed a few minutes ago stops being an opportunity for anyone sweeping the address space. Then deploy whatever you actually came here to run — a website, a node, a tunnel, a private model endpoint — on a base you can reason about.