VPS Security Hardening Checklist — 12 Steps After the First Login

Twelve ordered steps after first login — keys, default-deny firewall, unattended patches, fail2ban, restores — VPS from $6.00/mo annual-eff.

Published 2026-08-30 · Updated 2026-10-14 · FYRHost Editorial · 16 min read

Keys first, before anything touches the network

The highest-value step costs nothing and gets skipped most: a public key on the box and password authentication off, before the firewall, before updates, before anything else. A public IPv4 receives brute-force attempts within minutes of first boot, and password login is the weak default every one of those attempts exists to test. Until sshd_config says otherwise, every scanner on the route between you and the box is guessing at one credential.

The mechanism is two lines and one habit. Drop your public key into the new user's authorized_keys, then set PasswordAuthentication no and PermitRootLogin no in sshd_config, and reload the daemon. The sshd reference documents both directives and the match blocks if you need per-user exceptions. Create a named sudo account for daily work and reserve root for console and rescue contexts, where it belongs.

Where this step breaks is the lockout: the directive lands, the session drops, and the key was never actually in place for the user you are logging in as. The discipline is trivial — keep the current session open, prove a second terminal authenticates with the key, and only then cut passwords off. The ssh client's verbose mode shows which key was offered, which turns guessing into reading.

The second mistake is half-measures: disabling root login but leaving passwords on for the sudo account, which moves the brute-force target without removing it. Key-only means key-only for every account that can authenticate over the network. Test from a machine without the key afterward — a connection refused on password is the goal, and it should stay that way through every rebuild.

With identity settled at the machine layer, the next surface is the one people forget the box even has: the hosting panel that can reset the machine, edit its DNS and read its invoices. That panel is attack surface too, and it gets its own step next.

The panel is attack surface too

A hardened VM behind a weak panel is a hardened VM somebody else can rebuild. The control panel resets boxes, edits DNS and reads billing, which makes it exactly the kind of credential an attacker wants and exactly the one operators protect least. The habit costs 2 minutes: 2-factor authentication on the panel account, before any workload lands on the machine it controls.

The mechanics stay boring on purpose. The signup credential is an inbox plus a 12-character password — or a bare token if you keep email out of it — and 2FA on top of that means a leaked password alone resets nothing. Treat the second factor as non-optional for any account that can destroy the box, the same way you treat root keys on the machine itself. Billing visibility also matters: an unfamiliar charge is often the first signal of a compromised upstream account.

Where panel hygiene breaks is the shared-account reflex: one login, five teammates, no second factor because the QR code lived in a chat that is gone. Give each human an account, attach 2FA to each, and revoke on departure the same day — an access list nobody has reviewed since 2 hires ago is a standing invitation. The panel holds the power to wipe the disk, so its access list deserves the same review the box's sudoers gets.

The second failure is mixing duties: the panel account that bills the company also configures production firewalls, so a phishing mail aimed at finance reaches infrastructure. Split the roles where the stakes split, keep the destructive capabilities behind the stricter factor, and the blast radius of any single credential shrinks to something recoverable — which is the actual goal of this entire checklist.

Identity settled on both layers — machine and panel — the next step is the network surface the box presents, and it starts with a rule simpler than any port list: deny first, then justify every exception in writing.

Default-deny networking, in the right order

The firewall rule that matters is the default, not the exceptions: deny inbound, then open 22 or your moved port, 80 and 443, and each port a running service genuinely needs — nothing else. The counter-intuitive part is the ordering: firewall before keys is how people lock themselves out, because a default-deny applied while you are password-only leaves exactly one credential, and it is the one being brute-forced.

The implementation is one tool and one file. ufw default deny incoming, then explicit allows for the ports above, keeps the policy readable; nftables does the same job with more ceremony. Bind admin interfaces to localhost or reach them through a tunnel — anything that answers publicly is being scanned right now, whatever port it hides on. The filtering guide covers what the platform edge already absorbs upstream, which is volumetric noise; the firewall here is for the doors you control.

Where default-deny breaks is drift: the test service on 8080, the debug endpoint on 9090, each added with a rule and never removed, until the policy reads like a diary. Re-read the firewall after every new service, and treat any allow rule whose purpose you cannot name in one sentence as a candidate for deletion. For brute-force noise specifically, fail2ban on the SSH jail makes the logs readable again — its project repository documents the jails, and the setup takes minutes.

If the checklist is running against a fresh box before real work begins, pick Sentry at $7.50/mo list — $6.00 annual-eff — as the practice cell: 2 vCPU, 4 GB and 60 GB NVMe is ample for a hardened control plane, and the same 12 steps apply unchanged when the workload later moves to bigger tiers. A fresh cell is also the honest time to move SSH off 22, now that keys are proven and the firewall can name the new port.

Network surface drawn and order enforced, the box survives its first week. What keeps it safe through the first year is not attention but machinery — patches that install without a calendar, bans that apply without a mood — and the machinery starts with the update path, next.

Patches without a calendar

The vulnerability that gets a small server taken is rarely exotic: it is the known CVE from 6 weeks ago that waited on a human to type an update command. Unattended security upgrades remove the human from the loop for exactly the class of patches where speed matters and judgment does not — library and package security fixes — while leaving kernel and major upgrades as the deliberate events they should be.

The mechanism is a timer, not a cron entry you will forget to migrate: apt-get install unattended-upgrades, enable the security origin, and confirm the schedule with systemctl list-timers — the apt timers should appear alongside the others. The crontab format still has its place for your own jobs, but vendor-shipped maintenance belongs in vendor-shipped timers, which survive distro upgrades and get tested by people who are not you.

Where patching breaks is the reboot debt: kernel fixes install, the running kernel stays old, and the box reports patched while running vulnerable code until someone reboots. Check /var/run/reboot-required weekly, schedule the reboot for a quiet hour, and let the checker nag until it is done. The second gap is silent failure — the timer disabled by a failed run months ago — so a monthly glance at the upgrade log is the cheap audit that catches it.

The third break is treating unattended upgrades as a substitute for reading the security feed on the components you actually run. Automated patching covers the distribution's packages; the Node app, the control panel or the game engine you installed by hand patches on its own schedule. Keep the list of hand-installed components to one screen, and give each one a release-notes habit — the checklist's value is that it makes the exceptions visible.

Patches on rails, the next machinery is behavioral: the brute-force noise that never stops, answered automatically so your logs stay readable and your mornings stay quiet. That is fail2ban, and it earns its install in the first week.

Brute-force noise and fail2ban

The scan noise against a public IPv4 never stops — hundreds of attempts a day against password auth, forever, from addresses that rotate — and after keys-only login the attempts are harmless but not free: they bury the log lines that matter. fail2ban answers automatically: watch the auth log, count failures per source, ban the address at the firewall for a window, unban it later without ceremony.

The setup is one package and one enabled jail: install it, enable the sshd jail with sensible thresholds, and watch fail2ban-client status sshd start filling with banned addresses. The project's documentation covers jail parameters; the default ban window on the order of 10 minutes suits a keys-only box, where bans are hygiene rather than defense. On VPS-sized workloads the daemon itself costs single-digit megabytes — the ROI is in log clarity, not CPU.

Where fail2ban breaks is self-inflicted: an aggressive ban window plus your own failed key agent plus a changed port equals a locked-out operator, so always whitelist the addresses you administer from before enabling jails. The second break is IPv6 blindness — a jail that matches only IPv4 syntax misses half the internet's scanner traffic, and the log fills again. Test both families by watching the ban list grow from each.

The third mistake is scaling bans into a security strategy: fail2ban against keys-only SSH is noise reduction, not the wall. The wall is the key requirement and the default-deny firewall; the bans just keep the doorstep visible. Once that framing holds, the temptation to ban whole countries or set 10-year windows disappears, along with the false comfort it provides.

Automatic answers running, the checklist turns to the step everyone believes they have and nobody has tested: backups. Not the copy — the restore, which is the only half that has ever saved anyone, and the subject of the next section.

Backups you have actually restored

A backup that has never been restored is a hope with a schedule. The complete pattern has three parts: snapshots as the pre-change rollback on the same host, an off-box copy on different storage for the host-dies case, and a quarterly restore into a scratch directory that proves the chain works end to end. Until the third part has run, the other two are assumptions about software you have not verified.

The mechanism is small and boring: snapshot before risky changes, ship an encrypted archive off-box nightly — rsync -a to a storage cell or an object store, keys held away from the box — and script the restore so it does not depend on your memory of the flags. A restore drill that takes 45 minutes quarterly costs 3 hours a year; the incident it prevents costs the database, the configuration and the trust of everyone who depended on the service.

Where backups break is the same-filesystem fantasy: the copy living on the box it protects survives everything except the box, which is the case that matters. The second break is unencrypted off-box copies — an archive readable by the storage provider extends your trust boundary to theirs, which is rarely a trade you meant to make. Encrypt client-side, hold the key outside both systems, and the off-box copy stays an asset under every failure scenario.

The third break is scope drift: the backup set that covered January's architecture silently misses June's new data volume, and the quarterly drill catches it — which is the drill's actual job. Restore, diff against expectations, note what the set missed, fix the set. A checklist that is never re-run against a changed architecture is a document, not a defense; the cadence question gets its own answer at the end of this guide.

Availability covered, one step remains for the data itself: what happens to the disk when the box is off, sold, or stolen — encryption at rest, and the trade-offs that come with it, next.

Data at rest: LUKS and the reboot question

Full-disk encryption on a VPS protects one precise scenario: storage media that outlive the box's control — decommissioned cells, snapshots in a catalog, a wedged machine you stop paying for. LUKS is the standard tool; the cryptsetup project maintains it, and the pattern is a container or partition opened after boot, with the plaintext living only in RAM while the machine runs.

The mechanism costs one passphrase and one decision. Create the container with cryptsetup luksFormat, open it with luksOpen, put the filesystem and data inside, and add the passphrase prompt to the boot path — or open it manually after each reboot for boxes that rarely restart. On a 16 GB machine the overhead is a rounding error; on NVMe the throughput cost is single-digit percent, which is the entire performance story.

Where at-rest encryption breaks is the automation paradox: a box that unseals itself unattended protects against media theft and nothing else, because anyone who can boot it can read it. The honest versions are the manual unseal after reboots, or the initramfs-SSH route that holds the key in your head rather than the machine's boot chain. Choose deliberately — convenience and the protection's scope move together, and pretending otherwise is how the trade gets made silently.

The second mistake is encrypting the swap you forgot: page cache and swap can hold secrets the encrypted volume never sees, and an unencrypted swap partition beside an encrypted root undoes the point. Encrypt swap with a random key per boot, and the at-rest story becomes coherent. When a dataset outgrows a VPS cell, order the Vault at $68.50/mo and carry the same discipline to metal — the tools are identical, and the passphrase habit transfers unchanged.

What is protected and how it boots are settled; one class of scanning remains, and it is not the operating system. The content you accept from other people — uploads, mail, user files — is where malicious files actually arrive, and that distinction is the next step.

Scan what you accept, not the operating system

Antivirus on a Linux server is usually aimed at the wrong threat: the base distribution is not the infection path — the content you accept from strangers is. Uploads, mail spools, user-generated files and anything a web app writes on behalf of the public are where malicious files land, and a ClamAV-class scanner pointed at those directories earns its keep, while one pointed at the whole filesystem burns CPU guarding an already-trusted layer.

The mechanism is scheduled, scoped scanning: clamscan -r against the upload directories on a cron or timer, fresh definitions first, quarantine rather than delete on match so a false positive is recoverable. The capabilities model matters here too — the scanner runs unprivileged against readable paths, and the detection it produces is only as good as the write permissions the web stack did not have in the first place.

Where scanning breaks is the performance instinct inverted: real-time scanning of everything on a 2 vCPU box taxes the workload to defend a layer that was never at risk. Scope to accepted content, schedule during quiet hours, and let the firewall, keys and patches handle the layers they are good at. For boxes that hold payment or key material — a self-hosted checkout, for instance, per the BTCPay guide — the accepted-content scan is one habit among several that keep the trust boundary honest.

The second break is quarantine amnesia: matches pile up unreviewed, and the signal that one upload pattern is being weaponized sits unread for months. A weekly glance at the quarantine report closes the loop — scanning without review is a motion, not a control, and the whole checklist exists to replace motions with controls that someone actually reads.

Twelve steps, one theme: each control is small, ordered, and verified by an action rather than an intention. The final section lines them up in the order to run them, from the first login to the quarterly restore drill, so the checklist becomes a sequence instead of a page.

The hardening checklist, in the order to run it

Step 1, before anything touches the network: the public key lands in the new user's authorized_keys, and a second terminal proves key login works. Step 2: PasswordAuthentication no and PermitRootLogin no go into sshd_config, the daemon reloads, and a named sudo account takes over daily work while root retreats to console contexts. Step 3: 2FA on the hosting panel, because it resets boxes and edits DNS.

Step 4: the firewall goes default-deny — allow 22 or the moved port, 80, 443, and each port a running service needs — with the rules in a versioned file. Step 5: fail2ban enabled on the SSH jail, your own addresses whitelisted first, both IP families checked. Step 6: unattended security upgrades on, the apt timers confirmed with systemctl list-timers, and the reboot-required flag watched weekly.

Step 7: admin interfaces bound to localhost or reached through tunnels, so nothing administrative answers publicly. Step 8: snapshots scheduled as the pre-change rollback, plus the encrypted off-box copy shipped nightly to storage the box cannot read. Step 9: LUKS under the sensitive data, swap encrypted with a per-boot key, and the unseal path chosen deliberately — manual after reboot or key-in-your-head via initramfs.

Step 10: the accepted-content scanner scheduled against upload directories only, with quarantine reviewed weekly. Step 11: the restore drill — quarterly, into a scratch directory, from the off-box copy, with the results diffed against what the backup set should contain. Step 12: the re-run rhythm — architecture changes trigger a full pass, panel access is re-checked whenever the team roster moves, and the dedicated tiers' IPMI gets the same 2FA discipline the panel has.

Run in that order on a fresh cell, the sequence takes one focused afternoon, and every step after the first three is machinery that keeps working without you. A hardened box is not a fortress — it is a machine whose known doors are few, watched, and written down, which is what the next audit, the next CVE and the next 3 a.m. will actually test.