Guide

Harden a fresh Debian VPS in ten minutes

A fresh VPS gets its first SSH brute-force attempt within minutes of booting. This is the short, opinionated checklist that shuts the easy doors — keys, firewall, fail2ban, auto-updates — before you install anything else.

Updated 2026-06-12

Deploy a VPS See pricing

Fenrir the wolf behind a fortified shield

Watch the auth log of any brand-new server and the internet’s background radiation appears immediately: credential-stuffing bots walking dictionaries against root, scanners probing for last year’s vulnerabilities, crawlers fingerprinting whatever answers on port 80. None of it is personal and almost all of it is automated, which is the good news — automated attacks are defeated by basic hygiene, applied before you deploy your actual workload. This guide is that hygiene, compressed to ten minutes on Debian 12/13 (everything translates to Ubuntu with minor edits). It is deliberately not a 4,000-word audit framework: it is the doors real bots actually try, closed in order of importance. Run it on every box you deploy here, then get on with the VPN, node or mail server you came for.

What this checklist deliberately leaves out

Port-knocking, kernel-hardening sysctl walls, SELinux/AppArmor tuning, intrusion-detection suites — all real tools, none of them first-day priorities on a single-purpose VPS, and several are easy to misconfigure into lockouts. The 80/20 here is honest: keys + no passwords + default-deny + auto-patches stops essentially all untargeted compromise. Add the heavy machinery when your threat model names an adversary who would defeat the basics — and if disk-level privacy matters to your model, remember the KVM layer lets you run full-disk encryption inside the guest.

Backups are part of security

Hardening reduces the odds; backups bound the damage. Weekly snapshots are included on every plan here, but snapshots live with the server — for anything you cannot lose, push encrypted offsite copies too: restic or borg to a second box (a $3.50 Pup in another region makes a tidy backup target) costs minutes to set up. Test a restore once; an untested backup is a hope, not a plan.

Log in once, update everything
```
apt update && apt full-upgrade -y && reboot
```
Templates are snapshots; the gap between the snapshot date and today is exactly the window the scanners probe. Patch first, reboot into the new kernel, then configure.

Create your user and install your SSH key

adduser ops && usermod -aG sudo ops
mkdir -p /home/ops/.ssh && nano /home/ops/.ssh/authorized_keys   # paste your ed25519 public key
chmod 700 /home/ops/.ssh && chmod 600 /home/ops/.ssh/authorized_keys && chown -R ops:ops /home/ops/.ssh

Generate the key on your local machine if you don’t have one: ssh-keygen -t ed25519. Test ssh ops@your-ip in a second terminal before proceeding.

Lock down sshd
Edit /etc/ssh/sshd_config.d/hardening.conf:
```
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
MaxAuthTries 3
AllowUsers ops
```
Then systemctl restart ssh — with your key-based session confirmed working first. Password guessing dies here: there is no password to guess. Moving the port to something nonstandard quiets log noise but is cosmetic, not security; do it for tidiness if you like.
Raise a default-deny firewall (nftables)
Debian’s native firewall, minimal ruleset in /etc/nftables.conf:
```
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    icmp type echo-request limit rate 5/second accept
    icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-advert } accept
  }
}
```
systemctl enable --now nftables. Open further ports only as you deploy the services that need them — the VPN guide opens 51820/udp, the mail guide 25/465/993, and so on. Default-deny means a forgotten test daemon is unreachable instead of a breach.
Add fail2ban for the noise that remains
```
apt install -y fail2ban
printf "[sshd]
enabled = true
maxretry = 4
bantime = 1h
" > /etc/fail2ban/jail.d/ssh.local
systemctl enable --now fail2ban
```
With passwords already disabled this is defence in depth plus log hygiene — repeat offenders get dropped at the firewall instead of filling your auth log.
Turn on unattended security updates
```
apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades
```
Debian’s security team now patches your box while you sleep. The single most effective line on this page measured per keystroke: most real compromises exploit patches that existed for months.
Two-minute verification pass
Confirm the posture from outside:
```
ssh root@your-ip          # must be refused
nmap -p- your-ip          # only 22 (and your service ports) open
last -a; journalctl -u ssh -n 50   # familiarise yourself with normal
```
Optionally add TOTP 2FA on your VPSCrypto account itself — the panel can rebuild or reimage the server, so it deserves the same care as root.

FAQ

Frequently asked questions

Should I change the SSH port?

It is log-noise control, not security — scanners find nonstandard ports in seconds with masscan. Do it if quiet logs help you notice real anomalies; never count it as a defence layer. The actual defences are keys-only auth and MaxAuthTries.

Do I need fail2ban if passwords are disabled?

Strictly no for SSH — there is nothing to brute-force. It stays on the list because it also covers other services you may add later (mail, panels) and keeps logs readable. Skip it on a minimalist box if you prefer.

Is a VPS firewall necessary when the host has DDoS protection?

They solve different problems. DDoS mitigation upstream absorbs floods; your nftables policy controls which services are reachable at all. Default-deny is about the daemon you forgot, not about gigabits.

What about Ubuntu instead of Debian?

Everything here applies; Ubuntu ships ufw as a friendlier front-end (ufw default deny incoming; ufw allow 22/tcp; ufw enable) and enables unattended-upgrades by default on recent releases. The sshd hardening is identical.

How do I recover if I lock myself out?

Use the console access in your client area — it is independent of sshd, so you can fix a bad config or restore a snapshot. This is also why you test the new SSH config in a second session before closing the first.

Deploy an offshore VPS in about a minute

No-KYC, crypto-paid, all-NVMe. Pick a tier, pay in Monero or any major coin, and get root in roughly 60 seconds.

Deploy a VPS Deploy API