Basic VPS security hardening: the first hour on a new server

The moment your VPS gets a public IP address, it becomes a target. Automated scanners sweep the internet constantly, and within minutes of boot you will see failed login attempts against the default SSH port from addresses all over the world. None of this is personal — it is bots trying millions of servers with common usernames and passwords, hoping a few are soft. The reassuring part is that you do not need to be a security expert to shut almost all of it down. A short, ordered checklist — done once, in your first hour — closes the doors that attackers actually use. This guide walks through those steps in the order that keeps you from locking yourself out.

Lock down how you log in

The single most valuable change is to stop logging in with a password and switch to SSH keys. A password can be guessed by a bot running through a dictionary; an SSH key pair cannot be brute-forced in any realistic timeframe. Generate a key on your own computer, copy the public half to the server (ssh-copy-id does this in one command), confirm you can log in with the key, and only then disable password authentication entirely in the SSH configuration. Do it in that order — test the key before you turn off passwords — or you risk locking yourself out of your own machine, which on an unmanaged box means a rescue-console rebuild. If you chose an unmanaged VPS to save money, this is exactly the kind of setup that is now yours to own.

While you are in there, stop logging in directly as root. Create an ordinary user, give it sudo rights, and set the SSH service to refuse root logins altogether. This means an attacker has to guess both a username and defeat your key, and it gives you an audit trail of who ran what. Moving SSH off the default port 22 is a common extra step: it will not stop a determined attacker, but it dramatically cuts the noise in your logs by dodging the dumb bots that only ever scan the standard port. Treat that one as tidying rather than real security — the key-based, no-root-login combination is what does the heavy lifting.

Shrink the attack surface

Every open port and every running service is a door someone can try. A firewall lets you close all of them except the few you actually use. On Ubuntu or Debian the simplest tool is UFW: allow SSH and whatever your application needs (typically ports 80 and 443 for a website), then deny everything else by default. It takes about four commands and it instantly removes whole categories of attack against database ports, mail daemons, and admin panels that you never meant to expose to the public internet in the first place — a real risk if you are running something like a database on your VPS that should only ever answer to your app.

The other half of a small attack surface is staying patched. The vast majority of successful server break-ins exploit a known bug that a security update had already fixed weeks earlier — the owner just never applied it. Turn on automatic security updates (the unattended-upgrades package on Debian-family systems does this cleanly) so critical patches land without you having to remember. Then uninstall anything the provider bundled that you do not need: a default image sometimes ships with a web server, a database, or sample services already running, and the safest service is one that is not installed. Fewer moving parts means fewer things to patch and fewer things to go wrong.

Keep it hardened over time

Two automated helpers cover the gap between your first hour and the months that follow. Install Fail2ban, which watches your logs and temporarily bans any IP that racks up failed login attempts — it turns the constant background brute-forcing into a non-event. Pair it with basic monitoring so you actually notice when something is wrong: even a simple uptime check plus a glance at authentication logs will tell you if an address is probing you or a service has fallen over. None of this stops a large volume-based attack on its own, so if your site is a likely target, read up separately on DDoS protection for a VPS, which is a different problem with different tools.

Finally, accept that hardening reduces risk but never eliminates it, so plan for the day something gets through. Working, tested backups and snapshots are what turn a compromise from a disaster into an afternoon of annoyance: if you can restore a clean image, an attacker who gets in has gained very little. Keep your backups somewhere the server itself cannot reach, so a break-in cannot wipe them too. Good security is really just these habits repeated — keys not passwords, a closed firewall, prompt patches, and a restore you have actually tested — and they matter far more than which provider you picked. If you are still choosing, weigh them alongside the rest of the choosing a VPS checklist and size the box with the calculator before you commit.