How to Secure a New Linux VPS in the First 30 Minutes (Ubuntu 24.04)

A fresh server is online for minutes before the first bot finds it. Thirty minutes of hardening decides whether that bot leaves empty-handed.

A new VPS is reachable from the whole internet the moment it boots. Automated scanners start probing port 22 within minutes, long before you have deployed your application. The good news: about 30 minutes of basic hardening blocks the vast majority of these attacks, and every step below is a copy-paste command.

This guide uses Ubuntu 24.04 LTS, the most common choice for a fresh KVM VPS. Debian 12 works almost identically; differences are noted where they matter.

What you will set up

• Fresh packages: known vulnerabilities patched before anything else runs.
• A non-root sudo user: you stop working as root day to day.
• SSH key authentication: passwords can no longer be brute-forced.
• A firewall (UFW): only the ports you actually use are open.
• Fail2ban: repeated failed logins get the source IP banned.
• Automatic security updates: critical patches install themselves.

Every service you do not run, every port you do not open and every privilege you do not grant is one less thing an attacker can use.

The principle of least privilege

Before you start

You need the server IP address and the root password (or root SSH key) from your control panel, plus a terminal: Terminal on macOS and Linux, or Windows Terminal / PowerShell on Windows 10 and 11, which ship with an OpenSSH client.

Important: keep your first SSH session open until the very end. If a change locks you out, that session is your way back in. Most providers, Hostry included, also offer a web console (VNC) in the control panel as a last resort.

Step 1. Update the system

Log in as root and install all pending updates:

ssh root@203.0.113.10
apt update && apt upgrade -y

If the upgrade installed a new kernel, reboot with reboot and reconnect. Replace 203.0.113.10 with your own server IP throughout this guide.

Step 2. Create a sudo user

Working as root means a single typo or compromised session has unlimited power. Create a regular user and give it administrative rights through sudo:

adduser deploy
usermod -aG sudo deploy

Pick any username you like instead of deploy, and set a strong password: you will need it for sudo.

Step 3. Switch to SSH keys

Generate a key on your computer

Run this on your local machine, not on the server. Ed25519 keys are short, fast and supported by every modern OpenSSH version:

ssh-keygen -t ed25519 -C "you@example.com"

Copy the key to the server

ssh-copy-id deploy@203.0.113.10

On Windows, where ssh-copy-id is not available, paste the contents of %USERPROFILE%\.ssh\id_ed25519.pub into /home/deploy/.ssh/authorized_keys on the server. Then open a new terminal and check that ssh deploy@203.0.113.10 logs you in without a password.

Disable root login and passwords

On Ubuntu 24.04, cloud images often ship a drop-in file that re-enables password logins, so put your settings in a file that is read first:

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

sudo sshd -t && sudo systemctl reload ssh

OpenSSH applies the first value it finds for each option, which is why the file name starts with 00-. The sshd -t check validates the syntax before reload, so a typo cannot take SSH down. On Debian the service is called sshd instead of ssh.

Step 4. Turn on the UFW firewall

UFW is a friendly front end for the Linux firewall and comes preinstalled on Ubuntu. Allow SSH before enabling it, or you will cut off your own connection:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp    # only if this server hosts a website
sudo ufw enable
sudo ufw status verbose

Open further ports only when a service really needs them, for example sudo ufw allow 25565/tcp for a Minecraft server.

Step 5. Install Fail2ban

Even with passwords disabled, bots will keep knocking. Fail2ban watches the SSH log and temporarily bans IP addresses that fail too many times, which also keeps your logs readable.

sudo apt install -y fail2ban python3-systemd

sudo tee /etc/fail2ban/jail.local >/dev/null <<'EOF'
[sshd]
enabled  = true
backend  = systemd
maxretry = 5
findtime = 10m
bantime  = 1h
EOF

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Step 6. Enable automatic security updates

Most real-world breaches exploit vulnerabilities that already have a patch. Let the server install security updates on its own:

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Answer Yes when asked. Security updates from the Ubuntu archive will now be applied daily.

Step 7. Verify what is exposed

Finally, list every service listening on the network and make sure there are no surprises:

sudo ss -tulpn

Anything bound to 0.0.0.0 or [::] is reachable from outside unless the firewall blocks it. Databases such as MySQL or Redis should normally listen on 127.0.0.1 only.

---

The checklist at a glance

Step	Protects against	Time
System update	Known, already patched vulnerabilities	3–5 min
Sudo user	Damage from mistakes and stolen root sessions	2 min
SSH keys, no root login	Password brute-force attacks	5 min
UFW firewall	Accidentally exposed services	3 min
Fail2ban	Persistent scanners and log noise	5 min
Unattended upgrades	New vulnerabilities after launch	2 min
Port audit	Forgotten or misconfigured services	2 min

What to do next

Basic hardening is the foundation, not the finish line. Depending on what the server runs, the next steps are usually:

1. Set up backups and test a restore at least once. A backup you have never restored is a hope, not a backup.
2. Add TLS to every public website. A free Let’s Encrypt certificate takes a couple of minutes.
3. Run a security audit with Lynis – see our guide on using Lynis on Ubuntu.
4. Hide SSH from scanners entirely with port knocking if the server is a high-value target.

FAQ

Should I change the default SSH port?

It reduces log noise from bots but is not real protection: a port scan finds the new port in seconds. With key-only authentication and Fail2ban in place, keeping port 22 is perfectly fine.

Do these steps work on Debian?

Yes. On Debian 12, install UFW first with apt install ufw and use systemctl reload sshd for SSH. Everything else is identical.

Is a managed server a better option?

If you would rather not maintain the operating system yourself, a managed dedicated server or cPanel web hosting moves most of this work to the provider. For full control at the lowest cost, a self-managed VPS with the checklist above is hard to beat.

Ready to try it? Deploy a KVM VPS with full root access in one of 18+ locations, ready in seconds, and run through this checklist on a clean server.