VPS Security Checklist: 12 Things to Do Right After Server Setup

You just got your VPS. Root password emailed to you. You can SSH in right now and start installing things. The problem: so can everyone else. Every new VPS on the internet gets scanned within minutes of going live. Automated bots probe port 22, test default credentials, and run dictionary attacks against SSH. This checklist covers the 12 things to do in the first session after provisioning, before you install anything else.

1. Create a Non-Root User

Never do daily work as root. Create a regular user with sudo access:

adduser deploy
usermod -aG sudo deploy

Use deploy (or any name that is not “admin” or “user”) for daily SSH sessions. Elevate to root only with sudo when needed.

2. Set Up SSH Key Authentication

Password-based SSH is a liability. Keys are what you want. On your local machine:

ssh-keygen -t ed25519 -C "deploy@server"
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@YOUR_SERVER_IP

Verify you can log in without a password:

ssh deploy@YOUR_SERVER_IP

Once confirmed, disable password authentication on the server:

sudo sed -i 's/^#*PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart sshd

3. Disable Root Login Over SSH

No reason for root to SSH in directly. Lock it down:

sudo sed -i 's/^#*PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl restart sshd

Root access still works through sudo from your deploy user.

4. Change the SSH Port

Default port 22 is scanned constantly. Change it to something non-standard:

sudo sed -i 's/^#*Port 22/Port 2222/' /etc/ssh/sshd_config
sudo systemctl restart sshd

Update your local SSH config to connect to the new port. Make sure your firewall allows it before restarting sshd.

5. Configure the Firewall (UFW)

Ubuntu ships with UFW (Uncomplicated Firewall). Enable it and allow only the ports you need:

sudo ufw default deny incoming
sudo ufw allow 2222/tcp    # SSH on your custom port
sudo ufw allow 80/tcp     # HTTP
sudo ufw allow 443/tcp    # HTTPS
sudo ufw enable

Check the active rules:

sudo ufw status verbose

Always allow your SSH port before enabling the firewall or you lock yourself out.

6. Install and Configure Fail2Ban

Fail2Ban monitors auth logs and bans IPs that fail authentication repeatedly. Install it:

sudo apt install -y fail2ban

The default config works, but adjust the ban time:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo sed -i 's/bantime = 10m/bantime = 1h/' /etc/fail2ban/jail.local
sudo systemctl enable --now fail2ban

Check it is running:

sudo fail2ban-client status

7. Enable Automatic Security Updates

Unattended-Upgrades handles this automatically on Ubuntu:

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Choose “Yes” when prompted. Verify it is active:

sudo systemctl status unattended-upgrades

Security updates apply automatically. Regular updates still need your attention.

8. Harden the SSH Configuration Further

Edit the SSH daemon config to tighten settings:

sudo nano /etc/ssh/sshd_config

Add or verify these settings:

MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
X11Forwarding no
AllowTcpForwarding no
PermitEmptyPasswords no

Then restart:

sudo systemctl restart sshd

MaxAuthTries 3 locks out an IP after 3 bad attempts. ClientAliveInterval keeps connections alive through NAT gateways. Disabling TCP and X11 forwarding closes off tunnels that an attacker could abuse.

9. Install an Intrusion Detection Tool

AIDE (Advanced Intrusion Detection Environment) monitors the filesystem for unexpected changes:

sudo apt install -y aide
sudo aideinit
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Run a manual check:

AIDE initializes by scanning the filesystem and building a database of file checksums. This first run takes a few minutes on larger disks. Subsequent runs compare against the baseline.

sudo aide --check

If the output is clean, no unexpected files have changed. Schedule daily checks via cron:

sudo crontab -e

Add this line:

0 3 * * * /usr/bin/aide --check | mail -s "AIDE report" root@localhost

10. Audit What Is Listening on the Network

Before you install anything, see what the base image exposes:

ss -tlnp

Look at the Local Address column. Only the ports you explicitly opened should appear here. If something unexpected shows up, investigate it before proceeding. Services like rpcbind, avahi-daemon, and telnet sometimes run by default on cloud images and are rarely needed on a VPS. They expand your attack surface for no reason.

If you see something you do not recognize, check what package installed it and whether it is safe to remove:

ss -tlnp | grep 111    # rpcbind
apt remove --purge rpcbind

11. Configure the Provider-Level Firewall

Most VPS providers offer a network-level firewall in their control panel, outside the operating system. This is a second layer that blocks traffic before it even reaches your server. Think of it as a gate in front of the building rather than a lock on the door.

Allow inbound on:

• TCP 2222 (your custom SSH port)
• TCP 80 (HTTP)
• TCP 443 (HTTPS)

Block everything else at the provider level. If a service on your server has an unpatched vulnerability, the provider-level firewall may block the exploit entirely. The OS firewall is your second line of defense, not your only one.

12. Take a Snapshot Before Going Further

After hardening but before installing other services, take a snapshot through the control panel. Name it post-setup-clean-state. This gives you a known-good state to roll back to if something breaks later. A botched config file, a misbehaving package, or a failed update is much easier to recover from when you can restore a snapshot in minutes rather than rebuilding from scratch.

Snapshots cost nothing on most providers and take 2 minutes to create. Set a calendar reminder to update it every few months after you have finalized your server setup.

Summary

The first session on a new VPS sets the security baseline for everything that runs on it. These 12 steps take under an hour and dramatically reduce the attack surface: SSH keys instead of passwords, a non-root user, firewall, Fail2Ban, automatic updates, and a snapshot you can roll back to. The bots scanning port 22 will move on to an easier target.