Linux Server Hardening Checklist for a New VPS

When a new Linux VPS goes online it is reachable from the whole internet within minutes, and automated scanners start trying default passwords almost immediately. This checklist covers the essential hardening steps in the order you should do them, before you install your website or application.

Commands use Ubuntu/Debian syntax; equivalents for AlmaLinux and Rocky Linux are noted where they differ.

1. Update everything

sudo apt update && sudo apt upgrade -y        # Ubuntu / Debian
sudo dnf upgrade -y                           # AlmaLinux / Rocky

Reboot if the kernel was updated.

2. Create a non-root user with sudo

Working as root all the time makes mistakes and compromises more damaging.

adduser deploy
usermod -aG sudo deploy        # on AlmaLinux/Rocky: usermod -aG wheel deploy

3. Set up SSH key authentication

On your own computer, create a key pair and copy the public key to the server:

ssh-keygen -t ed25519
ssh-copy-id deploy@your-server-ip

Log in with the key in a new terminal to confirm it works before changing anything else. A full walkthrough, including Windows, is in how to set up SSH key authentication.

4. Harden the SSH configuration

Edit /etc/ssh/sshd_config (or a file in /etc/ssh/sshd_config.d/):

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

Reload SSH and keep your existing session open while you test a new login. If something is wrong, you can still fix it. More options are in SSH security best practices.

5. Enable a firewall

Allow only what the server needs, starting with SSH:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

On AlmaLinux/Rocky, use firewalld (firewall-cmd --permanent --add-service=...). If your provider offers a network firewall, use it as an extra layer. See Linux firewall basics.

6. Turn on automatic security updates

• Ubuntu/Debian: install and enable unattended-upgrades.
• AlmaLinux/Rocky: use dnf-automatic configured for security updates.

Decide how kernel updates and reboots will be handled, for example a planned weekly reboot window.

7. Remove or disable unneeded services

List listening services:

sudo ss -tulpn

Anything listening that you do not need should be stopped and disabled. Databases and caches (MySQL, Redis) should listen only on localhost or a private network, never on a public IP without strict controls.

8. Protect against brute force

Install Fail2ban to ban IP addresses that repeatedly fail authentication for SSH and, optionally, your web applications. With password authentication disabled, SSH brute force cannot succeed, but Fail2ban still reduces log noise and load. See brute-force attack prevention.

9. Set the time zone and time sync

Accurate time matters for logs, certificates and 2FA codes. Make sure time synchronisation (for example systemd-timesyncd or chrony) is active.

10. Configure logging and monitoring

• Make sure system logs are kept and rotated.
• Set up monitoring and alerts for CPU, memory, disk space and services. See server monitoring basics.
• Consider sending logs off the server, so an attacker cannot erase them.

11. Set up backups before you need them

Configure automatic off-server backups of application data and configuration, and test a restore. See server backup strategy.

12. Harden the application stack

• Run each site or application under its own user.
• Keep file permissions tight; never use 777.
• Disable directory listing and server version banners.
• Configure HTTPS with modern TLS settings and security headers. See HTTP security headers explained.

Verifying your hardening

After working through the list, check the result from the outside and the inside:

• From another computer, scan your server's open ports (for example with nmap your-server-ip, only against servers you own). Only the ports you intended, such as 22, 80 and 443, should appear.
• Try a password login to SSH; it should be refused.
• Try logging in as root over SSH; it should be refused.
• On the server, run sudo ss -tulpn and confirm databases and caches listen only on 127.0.0.1.
• Check automatic updates are running: on Ubuntu, /var/log/unattended-upgrades/ shows recent activity.
• Check Fail2ban is active: sudo fail2ban-client status sshd.

Repeat this verification after major changes and a few times a year.

Hardening is not a one-time job

• New software can open new ports or create new users.
• Old releases reach end of life and stop receiving updates.
• Team members join and leave, and their keys and accounts must be added and removed.
• New vulnerabilities appear in software you already run.

Schedule a short quarterly review against this checklist, and keep notes of what you changed and why. A managed VPS moves much of this ongoing work to the provider.

Checklist summary

• System fully updated
• Non-root sudo user created
• SSH key login working
• Root login and password authentication disabled
• Firewall allowing only needed ports
• Automatic security updates enabled
• Unneeded services disabled; databases not public
• Fail2ban configured
• Time sync active
• Monitoring and alerts in place
• Off-server backups tested
• Application users, permissions and TLS configured

Frequently Asked Questions

Should I change the SSH port?

Moving SSH off port 22 reduces automated log noise but is not real protection. Key-only authentication is what matters.

Is a firewall needed if the provider has one?

Use both. A host firewall protects the server even if the network firewall is misconfigured, and vice versa.

How often should I review hardening?

After every major change, and at least every few months, checking for new listening services, users and outdated packages.

Related reading

For the fundamentals, see what is a VPS. If you would rather not do this yourself, a ServerNeed managed VPS includes security updates, firewall configuration and malware scanning.

Sources

• Ubuntu Server documentation: Security
• CIS Benchmarks