Tutorials

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: (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: (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): Then copy the public key to your server: 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: Find (or add) these lines and set them as shown: Save, then 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: 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: (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: 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: 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: 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: 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: 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: 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