Setting Up Your First VPS: A Security Checklist for the First Hour
The first security steps for a new Linux VPS: updates, a non-root user, SSH keys, a firewall, automatic patches, brute-force protection and backups.
A new VPS is reachable from the whole internet within seconds of being created, and automated scanners start trying to log in almost immediately. The first hour is the best time to lock it down, before you install your website. This checklist assumes a common Linux distribution such as Ubuntu or Debian; commands differ slightly on others.
- Update the system, create a regular user and switch to SSH key authentication.
- Turn on a firewall that allows only the ports you need.
- Enable automatic security updates, brute-force protection and off-server backups.
1. Update everything
Server images are often weeks or months old. Install all pending updates first:
sudo apt update && sudo apt upgrade
Reboot if the kernel was updated.
2. Create a non-root user
Working as root means every mistake has full power. Create a regular user and give it administrator rights through sudo:
adduser deploy then usermod -aG sudo deploy
3. Use SSH keys instead of passwords
On your own computer, create a key pair if you do not have one (for example with ssh-keygen -t ed25519), then copy the public key to the server with ssh-copy-id deploy@your-server-ip. Log in with the key in a new terminal to confirm it works before you change any settings.
Then edit the SSH server configuration (/etc/ssh/sshd_config or a file in sshd_config.d) and set:
PasswordAuthentication noPermitRootLogin no
Restart the SSH service and test again from a second session while keeping the first one open, so you cannot lock yourself out.
4. Turn on a firewall
Allow only what the server needs. With UFW on Ubuntu, a web server typically needs:
sudo ufw allow OpenSSHsudo ufw allow 80/tcpandsudo ufw allow 443/tcpsudo ufw enable
Many cloud providers also offer a network firewall in their dashboard; using both is fine. Never expose database ports such as 3306 or 5432 to the internet unless you have a specific reason and IP restrictions.
5. Enable automatic security updates
On Debian and Ubuntu, the unattended-upgrades package installs security patches automatically. It does not replace regular maintenance, but it closes the gap between a fix being released and you applying it.
6. Block repeated login attempts
Tools such as Fail2ban watch log files and temporarily block IP addresses that fail to log in too many times. With key-only SSH the risk is already low, but it reduces log noise and protects other services such as mail or admin panels.
7. Set the basics
- Set the hostname and the correct time zone, and make sure time synchronisation is active; accurate time matters for logs and certificates.
- Add swap space on small servers so memory spikes do not crash services.
- Remove or disable software you do not use.
8. Install your web stack carefully
- Install the web server, PHP or other runtime, and database from official repositories.
- Bind the database to
localhostand use a separate database user for each site with only the permissions it needs. - Run each site under its own system user where possible, so one compromised site cannot easily read another.
- Issue an SSL certificate and redirect HTTP to HTTPS.
9. Back up off the server
Take snapshots through your provider and also copy backups of files and databases to separate storage, such as an object storage bucket under a different account. Test a restore.
10. Monitor
- Set up uptime monitoring from outside the server.
- Watch disk space, memory and CPU; full disks are a common cause of outages.
- Review authentication logs occasionally for unusual activity.
Frequently asked questions
Should I change the SSH port?
It reduces automated noise in logs but is not real protection. Key-only login and a firewall matter far more.
Is a managed VPS safer?
It can be, because the provider handles updates and hardening. You still need strong passwords, secure applications and backups.
What if I lock myself out?
Most providers offer a web console or recovery mode that gives access without SSH. Find it before you need it.



