Why your VPS is vulnerable from the moment it's delivered
As soon as an IP address is assigned to your server, automated bots begin scanning it. Shodan, Censys, and thousands of malicious bots continuously catalog open ports across the Internet. A fresh Linux server exposes port 22 by default, with the root user accessible from any IP address worldwide. If your root password is weak — or if you reused a password already leaked in a data breach — your server can be compromised within hours or even minutes. Without a firewall, every port opened by your future applications is also reachable without restriction. Without an intrusion detection system, you will receive no alert when a brute-force attack is underway. This guide fixes these three fundamental problems using proven tools available directly in your distribution's official repositories.
What this guide sets up
- Non-root user with sudo — reduces attack surface by disabling direct root logins on your server
- SSH key authentication — eliminates brute-force attacks on passwords, only your private key grants access
- Disabled root SSH access — even if the root password is compromised, direct login remains impossible
- UFW firewall — blocks all incoming traffic by default and only allows explicitly declared ports
- fail2ban — automatically bans IP addresses that make repeated failed connection attempts
- Automatic security updates — critical patches apply without daily manual intervention on your server
- System clock synchronization — ensures consistent logs and valid TLS certificates across services
Prerequisites before you start
Before following this guide, make sure you have everything you need. Proper preparation will prevent you from getting stuck mid-way, especially during SSH configuration where a mistake can lock you out of the server entirely.
What you need
- Working root SSH access — you must be able to connect with
ssh [email protected]before starting - Ubuntu 22.04 LTS or Debian 12 — this guide is tested on both distributions, commands are identical
- A locally generated SSH key pair — run
ssh-keygen -t ed25519on your machine if you don't have one yet - A terminal with two tabs open — always keep an active root session during SSH configuration to avoid lockouts
The 7 hardening steps
Update the system
Start by syncing the package list and applying all available patches: apt update && apt upgrade -y. Reboot if a new kernel was installed: reboot. Reconnect as root after the reboot before proceeding to the next step.
Create a non-root user with sudo
Create a new user that will be your daily working account. Replace deploy with a name of your choice: adduser deploy. Follow the prompts to set a strong password. Then add this user to the sudo group: usermod -aG sudo deploy. Verify the addition worked: groups deploy should display deploy sudo.
Copy your SSH key to the new user
From your local machine, copy your public key to the deploy account: ssh-copy-id [email protected]. If ssh-copy-id is unavailable, copy manually by connecting as deploy, then run: mkdir -p ~/.ssh && chmod 700 ~/.ssh and paste your public key into ~/.ssh/authorized_keys with chmod 600 ~/.ssh/authorized_keys. Immediately test the connection in a new tab: ssh [email protected] — do not close the root session until this connection is confirmed.
Harden SSH configuration
Edit the SSH daemon configuration file: nano /etc/ssh/sshd_config. Modify or add these directives: PermitRootLogin no to forbid direct root access, PasswordAuthentication no to disable password authentication, and optionally Port 2222 to change the listening port (remember to open this port in UFW before restarting). Reload the configuration: systemctl reload sshd. Immediately test the connection with the new user from another terminal before closing your current session.
Configure UFW firewall
Install UFW if needed: apt install ufw -y. Set the default policy: ufw default deny incoming and ufw default allow outgoing. Allow the ports you need — if you changed the SSH port: ufw allow 2222/tcp, otherwise ufw allow 22/tcp. Add web ports: ufw allow 80/tcp and ufw allow 443/tcp. Enable the firewall: ufw enable. Confirm with Y when prompted. Verify the status: ufw status verbose.
Install and configure fail2ban
Install fail2ban: apt install fail2ban -y. Create a local configuration file to prevent your settings from being overwritten during updates: cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local. Edit jail.local to enable SSH protection: in the [sshd] section, ensure enabled = true is present and set bantime = 1h, findtime = 10m, maxretry = 5. Restart and enable the service: systemctl enable --now fail2ban. Verify that the SSH jail is active: fail2ban-client status sshd.
Enable automatic security updates
Install the unattended-upgrades package: apt install unattended-upgrades -y. Run the configuration wizard: dpkg-reconfigure -plow unattended-upgrades and answer Yes. To verify that automatic security updates are enabled, check /etc/apt/apt.conf.d/20auto-upgrades: both lines APT::Periodic::Update-Package-Lists "1"; and APT::Periodic::Unattended-Upgrade "1"; must be present. Also ensure systemd-timesyncd is active to keep the clock accurate: systemctl status systemd-timesyncd.
Critical tip: ALWAYS test the SSH connection with your new user in a second terminal BEFORE closing your root session. If you close the root session without verifying that key authentication works for deploy, you risk being permanently locked out of your server. If in doubt, use the KVM/VNC console available in your ServOrbit control panel.
Going further after initial hardening
Once the seven steps are complete, your server is considerably more secure than when it was delivered. But security is a continuous process, not a fixed state. Several complementary tools can further strengthen your security posture depending on your context. For environments that must meet compliance requirements (GDPR, PCI-DSS, ISO 27001), install auditd: apt install auditd -y then systemctl enable --now auditd. This daemon logs all sensitive system calls — command execution, file modifications, connections — and facilitates regulatory audits. For more advanced protection against botnets and coordinated scans, CrowdSec is an excellent alternative to fail2ban: it analyzes behaviors collaboratively, shares IP reputations among its users, and includes modern supervision dashboards. Our dedicated article details its installation and configuration on Ubuntu and Debian.
fail2ban vs CrowdSec: which one to choose?
| Criterion | fail2ban | CrowdSec |
|---|---|---|
| Installation ease | Very simple (apt) | Simple (official script) |
| Collective intelligence | No (local only) | Yes (shared database) |
| Supervision interface | CLI only | Web dashboard included |
| Resource consumption | Very low | Low to moderate |
| Best for | Simple servers, beginners | Multi-server infra, compliance |
Troubleshooting: common post-hardening issues
Even with a careful procedure, you may find yourself locked out or facing unexpected behavior. Here are the three most common situations and how to resolve them. First case: you locked yourself out of SSH. Connect via the KVM or VNC console in your ServOrbit panel, which provides direct server access independent of SSH. Once connected via console, you can fix the sshd configuration, add your key to authorized_keys, or reset a password. Second case: fail2ban banned your own IP address. Unban yourself from the console or from another IP: fail2ban-client set sshd unbanip YOUR_IP. To prevent this from recurring, add your static IP in the [DEFAULT] section of jail.local: ignoreip = 127.0.0.1/8 YOUR_IP. Third case: you changed the SSH port but forgot to open it in UFW before restarting sshd. Reconnect via console, add the missing rule ufw allow 2222/tcp and run ufw reload.
Conclusion
In under an hour, you have transformed a vulnerable server into a solid foundation: root SSH access is disabled, only cryptographic keys allow login, a firewall filters all unauthorized traffic, fail2ban automatically blocks attackers, and security patches apply without manual intervention. These seven steps represent the absolute minimum for any server exposed to the Internet. They do not replace application-level security (HTTPS, security headers, input validation) but they close the most exploited attack vectors on Linux VPS instances. Consider documenting them in your team runbook and applying them systematically to every new server you provision.
