Ubuntu VPS hardening checklist (2026)

0) Two rules before you start

1. Preserve access. Keep a second SSH session open while changing firewalls or SSH config.
2. Verify each step. Don’t stack five changes and hope. Make a change, test, move on.

1) Pre-flight

• Confirm Ubuntu version: lsb_release -a (or cat /etc/os-release).
• Confirm you have a provider console/recovery path (DigitalOcean console, etc.).
• List what must remain reachable: SSH, and any service ports you intentionally expose.

2) Updates (baseline hygiene)

Start with a clean, patched system.

sudo apt update
sudo apt -y upgrade
sudo apt -y autoremove

After upgrades, check whether a reboot is required:

sudo needs-restarting -r 2>/dev/null || [ -f /var/run/reboot-required ] && echo "Reboot required"

Decide your reboot posture (manual vs scheduled). For small private services, manual reboots are common — but document it.

3) Users and SSH access

Operate as a non-root user with sudo, and prefer SSH keys.

• Create a non-root sudo user (if you don’t already have one).
• Confirm you can log in as that user before tightening anything.
• Disable root SSH login (recommended for most VPS use).
• Disable password SSH auth (or at least limit it severely) once keys are confirmed.
• Test key-only login from a new terminal before closing your current session.

Do this carefully: lockouts are almost always self-inflicted.

4) Firewall: align provider + host rules

Cloud setups often have two firewalls:

• Provider firewall (e.g., DigitalOcean Cloud Firewall / security groups)
• Host firewall (UFW / nftables / iptables)

If either blocks a port, the service is unreachable.

Misalignment between provider and host firewalls is a common source of “it works locally but not externally” confusion.

Recommended approach

1. First, restrict at the provider layer (easy to roll back, reduces internet noise).
2. Then enable a host firewall with the same intent.

UFW example (conceptual)

Only open what you need. Don’t enable a deny-by-default firewall until SSH is explicitly allowed.

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

5) Fail2ban (optional, but useful for SSH)

Fail2ban is not a substitute for strong authentication, but it helps reduce brute-force noise.

• Install fail2ban.
• Enable the sshd jail (defaults are fine as a start).
• Verify it’s running and actually watching logs.

6) Automatic security updates

For many small deployments, enabling unattended security updates is a net win. The risk is unexpected changes. If you enable it, document the decision. For hobby or small private deployments, security-only updates are usually a reasonable trade-off.

• Enable security updates only (not full unattended upgrades of everything).
• Confirm it’s active and logging.

7) Reduce attack surface

Most compromise stories are boring: exposed services, default creds, ancient packages. Remove demo apps, test databases, and default services you don’t explicitly need.

• Remove unused services/packages.
• Check what’s listening: ss -tulpen
• Confirm only expected ports are reachable externally.

8) Backups and rollback

• Enable provider snapshots (at least weekly for active services).
• Before major changes, take a manual snapshot.
• Keep a short “restore checklist” (what to do first, what to verify).

9) Minimal verification checklist

• Can you still SSH in via public IP?
• Does the intended service still work (Mumble/WireGuard/etc.)?
• Do you have a tested recovery path?
• Does an external scan show only expected ports?

10) Common mistakes

• Locking yourself out by enabling UFW before allowing SSH.
• Disabling root login before confirming sudo access works.
• Enabling unattended full upgrades without understanding package impact.
• Forgetting provider firewall rules.