How to secure an Ubuntu VPS: 10 steps for the first hour

To secure an Ubuntu VPS, do four things first: log in over SSH with a key instead of a password, stop logging in as root, turn on a firewall that only opens the ports you use, and keep the system patched. Those four steps take about fifteen minutes and shut out most of the automated attacks that hit every new server.

This guide walks through ten concrete steps for Ubuntu 24.04 (most apply unchanged to Ubuntu 22.04 and Debian 12), with the exact commands, a way to check that each step took effect, and the mistakes that lock administrators out of their own servers. At the end we list what ZoPanel sets up for you, so you know which steps are still yours.

Why secure a VPS the moment it is created?

A VPS with a public IP gets port-scanned and sees SSH login attempts almost as soon as it boots. You can see it yourself: run sudo journalctl -u ssh after a day and you will find attempts for root, admin, test and other names, from addresses you have never heard of.

None of this is personal. Bots try weak passwords, forgotten services and unpatched software on millions of machines at once. The goal is not "nobody can ever attack me"; it is leave nothing easy for automated tools to exploit.

The Ubuntu VPS security checklist

Step	What to do	Priority
1	Update the system and turn on automatic security updates	Must
2	Create a sudo user; stop working as root	Must
3	Log in with an ed25519 SSH key	Must
4	Disable password and root logins over SSH	Must
5	Enable the UFW firewall	Must
6	Install Fail2ban	Should
7	Close services you do not need	Should
8	Sync the clock	Should
9	Back up off the server	Must
10	Watch logs and set alerts	Should

Before you start, make sure you can reach the server's out-of-band console (VNC or web console in your provider's dashboard). If you break SSH, that is your way back in.

Step 1: Update the system and enable automatic security updates

sudo apt update
sudo apt full-upgrade -y

Check whether a reboot is needed, usually after a kernel update:

[ -f /var/run/reboot-required ] && echo "Reboot required"

According to Ubuntu's documentation, Ubuntu Server ships with unattended-upgrades installed and applies security updates automatically from the start. By default it does not reboot, so kernel fixes only take effect after you restart. Schedule a regular reboot in a quiet hour.

On Debian 12, install it yourself:

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

Step 2: Create a separate sudo user

Working as root means every typo runs with full power. Create your own user:

sudo adduser ops
sudo usermod -aG sudo ops

Open a new terminal, run ssh ops@SERVER-IP, then sudo -v to confirm the account has sudo before you go further.

Step 3: Log in with an SSH key

On your own computer (not the VPS), create an ed25519 key pair, the type Ubuntu's OpenSSH documentation recommends:

ssh-keygen -t ed25519 -C "work-laptop"
ssh-copy-id ops@SERVER-IP

Give the key a passphrase so a stolen laptop does not mean an open server. Run ssh ops@SERVER-IP again: if you get in without being asked for the user's password, the key works.

Step 4: Disable password and root logins over SSH

This is the most valuable step and also the easiest one to lock yourself out with. Keep your current SSH session open until you have tested the result.

Ubuntu reads the files in /etc/ssh/sshd_config.d/ before the main config, and for sshd the first value it reads wins. Some cloud images ship a file such as 50-cloud-init.conf that sets PasswordAuthentication yes, so give your file a name starting with 00- to be read first:

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
EOF

Check the syntax, confirm the effective values, then restart SSH:

sudo sshd -t
sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication'
sudo systemctl restart ssh

Open a second terminal and log in with your key. Only close the old session once that works.

Should you change the SSH port?

Moving SSH off port 22 cuts log noise, but it does not replace key authentication. If you do it, remember that Ubuntu 24.04 uses socket activation for SSH, so restarting ssh after editing Port is not enough. Following Ubuntu's notes on socket activation:

sudo ufw allow 2222/tcp          # open the new port FIRST
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
sudo ss -tlnp | grep 2222

Connect on the new port, then remove the rule for port 22.

Step 5: Enable the UFW firewall

Deny everything incoming, then allow only what you need. Allow SSH before you enable UFW, or your current session is cut off.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

If your provider also has a cloud firewall or security group, configure it to match.

A note on Docker: the Docker documentation states plainly that Docker and UFW are incompatible: published container ports (-p 8080:80) are routed before UFW's rules apply. If an app should only be reached through a reverse proxy, publish it on 127.0.0.1:8080:80 instead of 8080:80.

Step 6: Install Fail2ban

Once SSH passwords are off, password guessing against SSH stops working, but Fail2ban still cuts noise and protects other services such as mail, FTP and login pages.

sudo apt install fail2ban python3-systemd
sudo tee /etc/fail2ban/jail.local > /dev/null <<'EOF'
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 ::1

[sshd]
enabled = true
backend = systemd
EOF
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

backend = systemd makes Fail2ban read the journal. That matters on Debian 12, which no longer installs rsyslog by default and therefore often has no /var/log/auth.log. Add your office IP to ignoreip so you never ban yourself.

Step 7: Close services you do not need

List everything that listens on a port:

sudo ss -tulpn

For each line, ask whether it really needs connections from the internet. MariaDB, PostgreSQL and Redis should almost always listen on 127.0.0.1 only. Remove software you do not use (sudo apt purge …) rather than just blocking its port.

Step 8: Sync the clock

Logs with the wrong time make incident investigation painful, and two-factor codes, licenses and certificates all depend on an accurate clock.

timedatectl
sudo timedatectl set-timezone UTC

System clock synchronized: yes means NTP is working.

Step 9: Back up off the server

Security also means being able to recover. Backups stored on the VPS itself disappear with it, whether the cause is ransomware or a provider outage. At a minimum:

• regular snapshots at your VPS provider;
• encrypted backups of files and databases somewhere else (S3-compatible storage, another server);
• a test restore, at least once. A backup you have never restored is a hope, not a plan.

Step 10: Watch logs and set alerts

A few commands worth knowing by heart:

sudo journalctl -u ssh --since today      # SSH logins
last -n 20                                # recent sessions
sudo fail2ban-client status sshd          # currently banned IPs
df -h                                     # disk filling up?

Better still, have alerts sent to you when a service stops, the disk fills or a certificate is about to expire, so nothing depends on you remembering to look.

Securing an Ubuntu VPS with ZoPanel: what is already done

If the VPS is for hosting websites, the ZoPanel installer takes care of many of these steps. From the security documentation:

• Updates: the installer upgrades all system packages and turns on automatic security updates (unattended-upgrades).
• Firewall: UFW is enabled at boot with only your SSH port, 80, 443 and 8888 (the panel) open. Optional components such as mail, DNS and FTP open their own ports when installed. Rules live under Security → Firewall.
• Fail2ban: an sshd jail (5 failures in 10 minutes, 1-hour ban) and a jail for panel logins (8 failures in 15 minutes, 1-hour ban).
• Isolation between sites: each account is its own Linux user with its own PHP-FPM pool, CPU/memory/process limits and disk quota, and /proc can be mounted with hidepid so customers cannot see each other's processes.
• Security Center: scores the server and the panel. It checks SSH root password login, SSH password authentication, Fail2ban, pending security updates and reboots, time sync, services exposed on public ports, extra UID 0 accounts and more, with a one-click Fix where a fix is safe. SSH fixes check that a key is set up first, so a fix cannot lock you out.
• The panel itself: two-factor authentication (which you can require for all admins), a panel IP allowlist, a tamper-evident activity log, a web application firewall (ModSecurity with the OWASP Core Rule Set) and a weekly malware scan.

What is still yours: creating the SSH key, keeping console access, and getting backups off the server. ZoPanel installs on a fresh server, so a sensible order is: create the VPS, add your SSH key, check the requirements and install ZoPanel, then open Security Center and work through anything still red.

For why the hosting panel itself should be designed to limit the damage of a compromise, see Why a hosting control panel should never run as root.

Mistakes that lock you out of your VPS

1. Enabling UFW before allowing SSH. Your session drops instantly. Always ufw allow OpenSSH first.
2. Disabling passwords before testing the key. Test key login in a second terminal first.
3. Changing the SSH port without opening it in UFW and the cloud firewall, or forgetting restart ssh.socket on Ubuntu 24.04.
4. Closing the old SSH session too early. Keep it until a new session works.
5. Assuming UFW protects Docker containers. It does not, for published ports.
6. Keeping backups only on the same VPS. They are gone when the VPS is.

Conclusion

A secure Ubuntu VPS does not need expensive tools. SSH keys, no passwords, a firewall, automatic patches and off-server backups close most of the doors bots look for. The hard part is doing it in the right order so you do not lock yourself out, and keeping it up afterwards.

If the server will host websites, you can install ZoPanel for free (the Free plan covers 3 hosting accounts, 10 websites and 10 databases, with no time limit) and get the firewall, Fail2ban, per-site isolation and a Security Center that keeps checking for you. Next read: protecting your VPS from SSH brute force.

Frequently asked questions

What should I do first to secure an Ubuntu VPS?

Update the system, log in with an SSH key, disable password and root logins over SSH, and enable UFW with only SSH, 80 and 443 open. Then install Fail2ban and set up backups that leave the server.

Should I change the default SSH port 22?

It reduces automated noise in the logs but adds little real security if you already use keys and have passwords off. If you change it on Ubuntu 24.04, run systemctl daemon-reload and systemctl restart ssh.socket, and open the new port in the firewall first.

Does Ubuntu install security updates automatically?

Yes. Ubuntu Server installs and enables unattended-upgrades for security updates, but it does not reboot by default. Kernel fixes only apply after a restart, so schedule regular reboots.

Why doesn't UFW block Docker ports?

Docker adds its own NAT rules that redirect traffic to containers before UFW's rules are evaluated. Publish container ports on 127.0.0.1 and put nginx in front as a reverse proxy.

Does installing a control panel make a VPS less secure?

It can, if the panel runs as root and is exposed to the internet without protection. Choose a panel with privilege separation, two-factor authentication, an IP allowlist and a clear update policy, and keep it updated.