How to Secure Your VPS: 12 Essential Steps

The fastest way to secure a VPS is to lock down remote access first, then add layers around it: SSH keys instead of passwords, a firewall, automatic patching, monitoring, and tested backups. This guide walks through 12 concrete steps you can apply on a fresh Linux server in an afternoon, with copy-pasteable commands for each one.

A new VPS starts getting probed within minutes of coming online. Automated bots scan the internet for open SSH ports and try common username and password combinations around the clock. According to Verizon's 2025 Data Breach Investigations Report, brute-force attacks against web applications nearly tripled year over year, climbing from roughly 20% to about 60% of basic web app attacks, and 88% of those attacks involved stolen credentials (Descope analysis of the 2025 DBIR). The steps below are ordered so the highest-impact protections come first.

Step 1: Create a non-root user with sudo

Working as root all the time means one mistake or one leaked credential hands over full control. Create a regular user and give it sudo rights instead.

adduser deploy
usermod -aG sudo deploy

Log in as deploy from now on and use sudo only when you need elevated privileges. This limits the damage any single command or compromised session can do.

Step 2: Generate an SSH key pair

Passwords can be guessed. A modern SSH key effectively cannot. Generate an Ed25519 key on your local machine, not on the server:

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

Ed25519 keys are short, fast, and strong, which is why the CIS Benchmarks recommend them over older RSA keys. Your private key stays on your laptop in ~/.ssh/id_ed25519. Never copy it to the server or share it.

Step 3: Install your public key on the VPS

Copy the public half of the key to your new user account:

ssh-copy-id deploy@your-server-ip

Then open a fresh terminal and confirm you can log in with the key before changing anything else:

ssh deploy@your-server-ip

Keep your current session open until the new key-based login works. If you lock yourself out before testing, you will need console access to recover.

Step 4: Harden SSH and disable password login

This is the single most valuable change on the list. Edit the SSH daemon config:

sudo nano /etc/ssh/sshd_config

Set these values:

PasswordAuthentication no
PermitRootLogin no
PermitEmptyPasswords no

Then reload SSH:

sudo systemctl restart ssh

PasswordAuthentication no shuts the door on every password-guessing bot at once. PermitRootLogin no forces attackers to know a valid username as well as hold a key. These settings map directly to the CIS Linux hardening controls, and they are the reason a well-configured server shrugs off the brute-force traffic that fills the internet.

Step 5: Configure a firewall

A firewall decides which ports the outside world can even reach. On Ubuntu or Debian, ufw is the simplest option:

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

Open only the ports your services actually use. If you are not running a web server yet, skip ports 80 and 443 until you are. Check the active rules any time with sudo ufw status verbose.

Step 6: Install fail2ban

Fail2ban watches your logs and temporarily bans any IP that racks up failed logins. Install it and enable the SSH jail:

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

Out of the box it bans an IP for 10 minutes after 5 failed attempts within a 10-minute window. To tune it, create /etc/fail2ban/jail.local and override bantime, maxretry, and findtime there rather than editing the default config. This alone clears a huge amount of brute-force noise from your logs.

Step 7: Keep software patched automatically

Attackers move fast on newly disclosed flaws, so leaving known vulnerabilities unpatched is one of the easiest ways to lose a server. On Debian and Ubuntu, unattended-upgrades applies security updates without you logging in:

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

For everything else, run manual updates on a schedule:

sudo apt update && sudo apt upgrade

Automatic security patching means a critical fix lands in hours, not whenever you next happen to log in.

Step 8: Change the default SSH port (optional)

Moving SSH off port 22 to something like 2222 will not stop a determined attacker, but it dramatically cuts the volume of automated scan traffic hitting your logs. Set Port 2222 in sshd_config, allow the new port in your firewall, then restart SSH. Treat this as noise reduction, not real security.

Step 9: Set up monitoring

You cannot respond to what you cannot see. At a minimum, keep an eye on authentication logs, resource usage, and running services. Lightweight tools help:

• sudo journalctl -u ssh to review SSH activity
• htop for live CPU, memory, and process visibility
• Log-based alerts for repeated auth failures or unexpected outbound traffic

Set alerts so a spike in failed logins or CPU usage reaches you instead of sitting silently in a file. On a Bytehosty KVM VPS you also get the Virtualizor control panel for a quick view of resource usage and reinstall or reboot controls when something goes wrong.

Step 10: Add intrusion detection

A file integrity or intrusion detection tool tells you when something on the system changes unexpectedly. Options like AIDE (file integrity checks) or a rootkit scanner such as rkhunter give you a tripwire:

sudo apt install rkhunter
sudo rkhunter --check

Run scans on a schedule and review the output. The goal is simple: turn a quiet compromise into a visible alert you can act on before it spreads.

Step 11: Plan backups as a security layer

Backups are the control that saves you when every other layer fails. A recent, tested backup is often the fastest way back from ransomware, a botched update, or a full compromise. Follow the 3-2-1 pattern: three copies of your data, on two types of media, with one copy off-site.

The key word is off-server. A backup sitting on the same VPS disappears with the server. Store copies somewhere the compromised machine cannot reach, and actually test a restore. An untested backup is only a hope, not a recovery plan. If you are picking a host, look at what recovery tooling ships with it. Bytehosty's DDoS-protected VPS plans include the Virtualizor panel, which makes OS reinstalls and clean rebuilds straightforward when you need to start fresh from a backup.

Step 12: Add DDoS protection and network hardening

Application-layer hardening does nothing against a flood of traffic aimed at knocking your server offline. Network-level DDoS mitigation absorbs or filters that traffic upstream before it saturates your uplink. Every Bytehosty plan runs behind AS203446 SmartMitigate DDoS protection, so volumetric attacks are handled at the network edge rather than landing on your VPS. If you host anything public-facing, from a game server to an API, treat network protection as part of your security baseline rather than an add-on.

How to secure a VPS: putting it together

Security on a VPS is cumulative. Each step above removes an attack path or shortens your recovery time, and the first four steps alone stop the overwhelming majority of automated attacks that new servers face. If you only do a handful today, do these: create a non-root user, switch to SSH keys, disable password login, and turn on a firewall.

For the next move, set up unattended-upgrades so your patching runs itself, then schedule and test one off-server backup this week. If you are still choosing where to run your workload, our step-by-step VPS setup guide walks through a clean, hardened install from first boot.