A fresh VPS is exposed to automated attacks within minutes of coming online — this checklist walks you through the first hour of hardening that keeps it yours.
Every new server starts life with the same weaknesses: a default root login, a password-only SSH door, wide-open firewall, and no automatic patching. Bots scan the entire IPv4 space continuously, so "nobody knows my IP yet" is never true.
This guide is an ordered, copy-ready hardening checklist. Work top to bottom on a fresh Debian or Ubuntu box and you will close the openings attackers actually use, not the ones security theatre worries about.
Before you touch the server
Two decisions made before your first login save hours later. Get your SSH key ready and pick a non-root user name.
- 1
Generate a modern SSH key
On your own machine run ssh-keygen -t ed25519 -C "you@device". Ed25519 keys are short, fast, and stronger than the old RSA-2048 default.
- 2
Keep the private key off the server
The private half never leaves your laptop. You only ever copy the .pub file to hosts. Losing this rule is how people lock themselves into re-provisioning.
- 3
Note your provisioning credentials
Most providers email a temporary root password or inject your key at build time. If a key was injected, you can skip straight to creating a user.
If your host injects your SSH key at deploy time, you never have a password-based window at all — the single biggest attack surface is gone before boot.
Step 1 — Patch everything, then keep it patched
An unpatched kernel or OpenSSL is the one flaw no firewall rule fixes. Update before you configure anything else.
- Debian/Ubuntu: apt update && apt full-upgrade -y then reboot if the kernel changed.
- Enable unattended-upgrades so security patches land automatically: apt install unattended-upgrades && dpkg-reconfigure unattended-upgrades.
- Reboot on a schedule you control — set Unattended-Upgrade::Automatic-Reboot to a quiet hour rather than leaving kernels half-applied.
Step 2 — Create a real user and retire root
Logging in as root means a single compromised session owns the whole machine and leaves no audit trail. Give yourself a named sudo account instead.
- 1
Add the user
adduser deploy then usermod -aG sudo deploy (use wheel on RHEL-family systems).
- 2
Install your key for that user
From your laptop: ssh-copy-id deploy@your-server-ip. This writes your public key to ~/.ssh/authorized_keys with correct permissions.
- 3
Test before you lock the door
Open a second terminal and confirm you can ssh deploy@server and run sudo -v. Never disable root or passwords until a fresh session works.
Golden rule of SSH hardening: keep your current session open and prove the new login works in a second window before you change any auth setting. This one habit prevents almost every lockout.
Step 3 — SSH hardening, the part that matters most
SSH is the front door of every VPS, and it is where the majority of automated login attempts hammer. Edit /etc/ssh/sshd_config (or a drop-in in /etc/ssh/sshd_config.d/) and set these keys.
Apply with sshd -t to validate syntax, then systemctl restart ssh. If sshd -t reports an error, fix it before restarting or you may drop the daemon.
Changing the SSH port from 22 is optional and only cuts log noise — it is obscurity, not security. Once PasswordAuthentication is off, port scanning bots have nothing to guess, so spend your effort on keys rather than port games.
Step 4 — Turn on a default-deny firewall
A hardened SSH daemon still shares the machine with every other listening service. A firewall makes "closed unless I opened it" the default.
- 1
Set the baseline
With ufw: ufw default deny incoming and ufw default allow outgoing.
- 2
Allow only what you serve
ufw allow OpenSSH, plus ufw allow 80,443/tcp only if this box actually hosts web traffic.
- 3
Enable and verify
ufw enable then ufw status verbose. Anything not listed is now unreachable from the internet.
Firewall the SSH rule in before you enable ufw. Enabling a default-deny firewall without an allow rule for your own port will cut your session.
Step 5 — Slow down brute force with Fail2ban
Even with passwords disabled, bots keep knocking and bloat your logs. Fail2ban bans repeat offenders at the firewall level.
- apt install fail2ban — the shipped sshd jail works out of the box.
- Copy jail.conf to jail.local and raise bantime (e.g. 1h) and lower maxretry (e.g. 3) to taste.
- Check it is working with fail2ban-client status sshd to see banned IP counts.
Step 6 — Reduce the attack surface
The safest service is one that is not running. Audit what listens and trim what you do not need.
Audit open ports
ss -tulpn lists every listening socket and the process behind it. Investigate anything you did not deliberately start.
Remove dead packages
Disable or uninstall services you are not using — a database or mail agent left running is pure liability.
Isolate services
Bind internal daemons like databases to 127.0.0.1 so they are never exposed even if the firewall slips.
Lock down permissions
Ensure ~/.ssh is 700 and authorized_keys is 600. Wrong permissions make sshd silently ignore your key.
Step 7 — Log, monitor, and know your baseline
Hardening is not a one-time event. You need to notice when something changes.
- Review auth activity with journalctl -u ssh or lastb for failed logins.
- Consider auditd for a tamper-evident record of privileged actions.
- Keep an off-server backup of /etc and your data so a compromised box can be rebuilt clean rather than trusted after the fact.
Where the host itself matters
Software hardening protects the OS, but the provider decides what sits underneath it — network filtering, payment trail, and whether an identity is ever tied to the server. On ChainVPS every plan ships with DDoS filtering and unmetered bandwidth, and servers are paid from a prepaid crypto balance across 21 coins including Monero, with no KYC. If your threat model includes not linking a server to your identity, our offshore VPS plans are built for exactly that.
Location is part of hardening too: six of our fifteen regions are privacy-tier jurisdictions (NL, CH, RO, IS, MD, LU). Pairing a hardened OS with an offshore dedicated server keeps both the software and the legal surface tight.
The one-hour checklist, condensed
- Full system update + automatic security patches enabled
- Named sudo user created, key installed, login tested
- Root SSH login and password auth both disabled
- SSH config validated with sshd -t and reloaded
- Default-deny firewall active, only needed ports open
- Fail2ban running on the sshd jail
- Open ports audited, unused services removed
- Off-server backup and log review in place
Should I change the SSH port to something other than 22?
It is optional and only reduces log noise, not real risk. Once password authentication is off and keys are required, moving the port adds obscurity rather than security — prioritise disabling passwords first.
Is disabling password authentication safe if I only have one key?
Yes, provided you have tested the key login in a separate session and keep a backup of the private key. Many providers also offer a web console or recovery mode, so you are never truly locked out of the hardware.
Do I still need a firewall if SSH is the only service?
Yes. A default-deny firewall protects you from services you forget you installed and from anything a future package quietly starts listening on. It costs nothing and closes surprises.
How often should I revisit hardening?
Automatic security updates handle the daily work, but review listening ports and auth logs after any major software install and at least monthly. Treat a hardened baseline as something you verify, not something you set once and forget.
