How to Secure a New VPS: 12 Steps to Take in the First Hour
A fresh VPS is scanned by bots within minutes. Twelve practical steps for Ubuntu and Debian servers, from SSH keys and a firewall to updates and backups.
The moment a new VPS gets a public IP address, it starts receiving login attempts. Nobody is targeting you personally. Automated scanners sweep whole address ranges around the clock, trying root with common passwords on port 22, and a new server looks exactly like every other easy target.
The good news is that the fixes are well known, and most take a few minutes. This guide walks through them in the order that makes sense on a brand-new Ubuntu or Debian server. The commands assume a current release, such as Ubuntu 26.04 LTS or Debian 13 "trixie". Other distributions use different package tools, but the ideas are the same.
1. Update everything first
Images are built weeks or months before you boot them, so the first job is to install whatever security fixes came out since:
apt update && apt full-upgrade -y
reboot
The reboot matters if the kernel was updated. A patched kernel on disk does nothing until it is the one running.
2. Create a normal user with sudo
Working as root all day means every typo runs with full power. Create your own account and give it sudo rights instead:
adduser deploy
usermod -aG sudo deploy
Pick any username you like. Avoid admin and user, since bots try those right after root.
3. Switch to SSH keys
Passwords can be guessed. A modern SSH key effectively can't. On your own computer
Compare hosts the community actually votes for
Real customers rank providers by speed, support and value — no paid placements.
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
Both options are documented in the OpenSSH manual (sshd_config). One catch trips people up on cloud images: a file such as 50-cloud-init.conf in the same folder may set PasswordAuthentication yes. For most options, OpenSSH uses the first value it reads, and files load in name order. That's why the file above starts with 10-. Check what the server will actually use, then reload:
Keep your current session open and test a fresh login before you log out.
5. Turn on a firewall
A firewall means only the services you choose are reachable. On Ubuntu, ufw is the easiest option. Allow SSH before you enable it, or you'll cut off your own connection:
Only open 80 and 443 if the server will run a website. A database server usually shouldn't expose anything except SSH.
Many providers also offer a network firewall in their control panel. Use both if you can. The provider's firewall blocks traffic before it ever reaches your server, so it still protects you if a config change goes wrong on the box.
6. Make security updates automatic
On Ubuntu Server, the unattended-upgrades package is installed by default and set to apply security updates daily (Ubuntu docs). Check that it's actually on, since some provider images change the defaults:
systemctl status unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades
On Debian, install it yourself with sudo apt install unattended-upgrades and run sudo dpkg-reconfigure unattended-upgrades to switch it on.
Automatic updates don't reboot the server by default, so kernel fixes wait until you restart. Check for /var/run/reboot-required now and then, or set a quiet reboot window in the same config.
7. Add Fail2ban
Even with passwords off, SSH bots fill your logs with noise. Fail2ban watches the logs and temporarily bans IPs that keep failing:
The defaults protect SSH out of the box on Debian and Ubuntu. Be aware it only works on services whose logs it reads. It doesn't replace the steps above; it adds a layer on top.
8. Check what's listening
A clean image should run almost nothing, but some images ship with extras. List every service that accepts connections:
sudo ss -tulpn
For each line, ask whether you need it. If not, stop it and disable it with sudo systemctl disable --now <service>. Anything that only needs to be reached locally, like a database or Redis, should listen on 127.0.0.1, not 0.0.0.0.
9. Set the time zone and check clock sync
Correct time sounds boring, but it matters. TLS certificates, log timestamps and two-factor codes all depend on an accurate clock:
timedatectl
sudo timedatectl set-timezone UTC
Look for System clock synchronized: yes. Many admins keep servers on UTC so logs from different machines line up.
10. Set up backups before you need them
Security isn't only about keeping people out. It's also about recovering when something breaks, whether that's an attack, a bad update or your own mistake.
Turn on provider snapshots if they're offered. They're the fastest way to roll back a whole server.
Back up data separately: databases, uploads and config, sent to a different provider or storage account.
Test a restore. A backup you've never restored is only a hope.
If ransomware or an attacker gets root, anything they can reach from the server can be deleted too. Keep at least one copy somewhere the server can't write over.
11. Add basic monitoring
You want to hear about problems from an alert, not from a visitor. At minimum:
An external uptime check on your site or server. Our guide to uptime guarantees covers how to set one up with free tools.
Disk space alerts, since a full disk takes down databases and logging.
A look at sudo journalctl -p warning -b after big changes.
12. Write down what you did
Keep a short note of every change: users created, ports opened, config files edited. When something breaks in six months, or you build a second server, that note saves hours. Better still, script the steps once so the next server is identical.
What about changing the SSH port?
Moving SSH from port 22 to something like 2222 cuts down log noise a lot, because most bots only try 22. It doesn't add real protection, though. A scan of all ports finds the new one quickly. If you already use keys only, the port change is optional. If you do it, update the firewall rule before you restart SSH.
Managed vs unmanaged VPS
Everything above is your job on an unmanaged VPS. A managed VPS costs more, but the host handles updates, firewalls and often backups for you. If the steps in this guide look like more work than you want to own, that's a fair reason to pay for managed. Our comparison of shared, VPS, cloud and dedicated hosting goes into the trade-offs, and you can compare community-rated VPS providers here on HostingVotes.
FAQ
How quickly do bots find a new server?
Usually within minutes to hours. Scanners constantly sweep IPv4 address space, so every public address gets tested sooner or later. That's why the SSH steps belong in the first hour, not the first week.
Is a firewall enough on its own?
No. A firewall controls which ports are open. It does nothing about weak passwords on the ports you leave open, or about outdated software. You want keys, updates and a firewall together.
Do I still need Fail2ban if password login is off?
It's less critical, since key-only SSH can't be brute-forced in practice. It still cuts log noise and helps protect other services, such as a web login page, if you add jails for them.
Should I disable IPv6?
Not by default. Just make sure your firewall covers it. ufw handles IPv6 automatically when IPV6=yes is set in /etc/default/ufw, which is the default on Ubuntu.
How often should I review the server?
A quick check once a month is a good habit: look for pending reboots, review open ports with ss -tulpn, confirm backups ran and remove users who no longer need access.
