How to Secure Your VPS: 12 Essential Steps for Beginners

The moment your VPS goes online, automated bots start probing it. They scan for open ports, guess passwords, and hunt for unpatched software — thousands of attempts per day, on every server, everywhere. This is not personal; it is just how the internet works.

The good news: basic server hardening stops the vast majority of these attacks, and none of it is difficult. Follow these 12 essential steps to secure your VPS and your server will be dramatically safer than the average unprotected machine.

Before you begin: You will need root or sudo access over SSH. Work through the steps in order, and never lock yourself out — when changing SSH settings (steps 4–5), always keep your current session open and test a new login before closing it. If your provider offers snapshots, take one before you start.

Step 1: Update Your System

Fresh VPS images are often weeks or months behind on security patches. Update everything first:

sudo apt update && sudo apt upgrade -y

(On RHEL-based systems like AlmaLinux or Rocky Linux, use sudo dnf update -y instead.) Reboot afterward if the kernel was updated: sudo reboot.

Step 2: Create a Non-Root User With Sudo Access

You should not do daily work as root — one typo as root can destroy the system, and attackers specifically target the root account. Create your own user:

adduser deploy
usermod -aG sudo deploy

(On RHEL-based systems, use usermod -aG wheel deploy.) Log in as this user from now on and use sudo when you need elevated privileges.

Step 3: Set Up SSH Key Authentication

Passwords can be guessed; cryptographic keys effectively cannot. Generate a key pair on your own computer (not the server):

ssh-keygen -t ed25519 -C "your-email@example.com"

Then copy the public key to your server:

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

Enter your password one last time, and from then on you can log in with the key. If ssh-copy-id is not available, manually append the contents of ~/.ssh/id_ed25519.pub to ~/.ssh/authorized_keys on the server and set permissions with chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys.

Step 4: Disable Root Login and Password Authentication

Once key-based login works, shut the two biggest attack doors. Edit the SSH configuration:

sudo nano /etc/ssh/sshd_config

Find (or add) these lines and set them as shown:

PermitRootLogin no
PasswordAuthentication no

Save, then restart SSH:

sudo systemctl restart ssh

(On RHEL-based systems the service is called sshd.) Critical: before closing your current session, open a new terminal and verify you can still log in with your key. If something is wrong, your existing session lets you fix it.

Step 5: Consider Changing the Default SSH Port (Optional)

Moving SSH from port 22 to something like 2222 does not make you truly more secure, but it eliminates nearly all automated scanning noise from your logs. If you do it:

1. In sshd_config, set Port 2222 (pick an unused port above 1024).
2. Update your firewall first to allow the new port, or you will lock yourself out.
3. Restart SSH and test with ssh -p 2222 deploy@your-server-ip.

Skip this step if it feels risky — steps 1–4 provide the real protection.

Step 6: Enable a Firewall

Ubuntu ships with UFW (Uncomplicated Firewall). Allow SSH before turning it on:

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

(If you changed the SSH port in step 5, use sudo ufw allow 2222/tcp instead.) Then open only the ports your services need — for a web server, that is typically sudo ufw allow 80,443/tcp. Every closed port is an attack surface you do not have.

Step 7: Install and Configure Fail2Ban

Fail2Ban watches your logs and temporarily bans IP addresses that show malicious patterns, like repeated failed logins:

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

The default configuration protects SSH out of the box, which is enough for most beginners. You can check banned IPs anytime with sudo fail2ban-client status sshd.

Step 8: Enable Automatic Security Updates

You will not always remember to patch manually. On Ubuntu/Debian, install unattended upgrades:

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

This automatically installs security patches. It does not replace occasional manual apt upgrade runs for non-security updates, but it closes the most dangerous window — the gap between a vulnerability’s disclosure and your next manual update.

Step 9: Use Strong, Unique Passwords Everywhere

With password authentication disabled for SSH, this mainly applies to application logins: database passwords, admin panels, and any web software you install. Use a password manager to generate and store long random passwords. Never reuse the password from another service — credential-stuffing attacks try leaked username/password pairs against every server they find.

Step 10: Set Up Regular Backups

Security is not only about keeping attackers out — it is about recovering when something goes wrong. Set up two layers of backups:

1. Provider snapshots: most VPS hosts offer one-click snapshots of your entire server. Schedule them regularly (daily or weekly depending on how often your data changes).
2. Off-site copies: keep copies of critical data somewhere other than your provider — another storage service or your local machine.

And the step everyone skips: test your restore process at least once. A backup you have never restored is a hope, not a plan.

Step 11: Harden Remote Desktop (Windows VPS Only)

If you run Windows Server instead of Linux:

• Ensure Network Level Authentication (NLA) is required for RDP connections.
• Use a long, unique administrator password.
• Restrict RDP access by IP in the Windows Firewall, or reach the server through a VPN instead of exposing port 3389 to the internet.
• Install Windows Updates promptly — RDP vulnerabilities do get patched, but only if you apply the patches.

Step 12: Monitor Logs and Set Up Alerts

Finally, keep an eye on your server. You do not need an enterprise monitoring stack on day one:

• Glance at authentication logs occasionally: sudo grep "Failed" /var/log/auth.log shows blocked login attempts (Fail2Ban at work).
• Enable your provider’s built-in monitoring alerts for high CPU, disk-full, and downtime — most offer this free.
• Consider a simple tool like logwatch for daily email summaries once you are comfortable.

The goal is to notice problems early: a full disk, a crashed service, or a sudden spike in traffic.

Keeping It Secure Over Time

Hardening is not a one-time event. Build these habits:

• Update monthly (or let automatic updates handle security patches).
• Review which ports are open whenever you install new software.
• Rotate credentials if anyone who had access leaves your team.
• Revisit your backups every few months and confirm restores still work.

Conclusion: Secure Your VPS in Under an Hour

Securing your VPS comes down to a handful of fundamentals: patch promptly, stop logging in as root, use SSH keys, close what you do not need behind a firewall, ban the bots automatically, and keep backups you have actually tested. None of these 12 steps takes more than a few minutes, and together they put your server ahead of the vast majority of machines on the internet. Do them once, maintain the habits, and you can stop worrying about the background noise of automated attacks.

Frequently Asked Questions

How long does it take to secure a VPS?

About 30–60 minutes for all 12 steps if you are following along for the first time. Most of that is waiting for updates to install. It is one of the highest-value hours you can spend on a new server.

Is changing the SSH port enough to secure my server?

No. Changing the port only reduces log noise from automated scanners. Real security comes from key-based authentication, disabled password logins, a firewall, and timely updates. Treat a port change as a supplement, never the main defense.

Do I need an antivirus on a Linux VPS?

For most server workloads, no. Linux servers are rarely targeted by traditional viruses; the real threats are weak credentials, unpatched software, and misconfiguration — which these 12 steps address. If your server handles file uploads from users, a scanner like ClamAV can be a reasonable extra layer.

What should I do if my VPS gets hacked?

Disconnect it from the network (or stop it) to prevent further damage, then assess: most professionals recommend rebuilding from a clean OS image and restoring data from a known-good backup rather than trying to “clean” a compromised system, since backdoors are hard to find reliably. After rebuilding, work out how the attacker got in — usually a weak password or unpatched software — and fix that gap first.