Securing Your VPS from Day One
A freshly provisioned VPS comes with default configurations that prioritize accessibility over security. The root password is often emailed in plaintext, SSH password authentication is enabled, and the firewall is wide open. Attackers scan for new VPS IPs within minutes of provisioning — automated bots will attempt SSH brute-force attacks on your server within the first hour it’s online. Completing these hardening steps during your first SSH session dramatically reduces your attack surface and gives you a secure foundation for all subsequent server management.
1. SSH Key Authentication (Disable Password Login)
Password-based SSH authentication is the most common entry point for automated attacks. SSH keys use asymmetric cryptography — a private key on your local machine and a public key on the server — making brute-force attacks computationally infeasible. An Ed25519 key, generated with 100 rounds of key derivation, would take billions of years to crack with current hardware.
From your local machine, generate an SSH key pair and copy it to your VPS:
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/vps_key
ssh-copy-id -i ~/.ssh/vps_key.pub root@YOUR_VPS_IP
Then on the VPS, harden the SSH daemon configuration:
sudo nano /etc/ssh/sshd_config
# Make these changes:
Port 2222 # Change from default port 22
PermitRootLogin prohibit-password # Root login with key only
PasswordAuthentication no # Disable password auth
PubkeyAuthentication yes # Enable key auth
MaxAuthTries 3 # Limit auth attempts
AllowUsers youruser # Only allow specific users
ClientAliveInterval 300 # Drop idle connections after 5 min
ClientAliveCountMax 2
sudo systemctl restart sshd
Critical: Before closing your current SSH session, open a second terminal window and test the new key-based login on your non-default port. Verify you can authenticate successfully before disconnecting your original session — otherwise you risk locking yourself out of the server.
2. Create a Non-Root User with Sudo
Operating as root full-time is dangerous — one mistyped command like rm -rf / or a script exploit running as root can destroy your entire filesystem. Create a regular user with sudo privileges for day-to-day administration:
sudo adduser deploy
sudo usermod -aG sudo deploy
# Copy SSH keys to the new user
sudo mkdir -p /home/deploy/.ssh
sudo cp ~/.ssh/authorized_keys /home/deploy/.ssh/
sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
All subsequent administration should use this user with sudo for privileged commands. After verifying sudo access works correctly, disable root SSH login entirely by setting PermitRootLogin no in sshd_config.
3. Configure the Firewall (UFW)
A default-deny firewall policy blocks all incoming traffic except the specific services you explicitly allow. UFW (Uncomplicated Firewall) provides a clean interface over iptables rules and is included by default on Ubuntu:
# Set default policies
sudo ufw default deny incoming
sudo ufw default allow outgoing
# Allow essential services only
sudo ufw allow 2222/tcp comment 'SSH on non-default port'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
# Enable the firewall
sudo ufw --force enable
# Check active rules
sudo ufw status verbose
Only open ports for services you actively use. If you run a database like MySQL or PostgreSQL, bind it to localhost (127.0.0.1 in the database config file) instead of opening a firewall port — databases should never be exposed to the internet directly. Use SSH tunneling or a VPN for remote database access.
4. Install and Configure Fail2ban
Fail2ban monitors system log files for repeated failed authentication attempts and temporarily bans offending IP addresses using firewall rules. This stops brute-force attacks against SSH, web login pages, and other services:
sudo apt install fail2ban
# Create a local jail configuration (never edit jail.conf directly)
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local
Configure the SSH jail with settings appropriate for your non-default port:
[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
findtime = 10m
bantime = 1h
Restart Fail2ban and verify it is actively monitoring your SSH logs:
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd
5. Configure Automatic Security Updates
Unpatched software is the leading cause of server compromises. The 2024 Verizon Data Breach Investigations Report found that over 60% of breaches involved known vulnerabilities with patches available but not applied. Configure automatic installation of security updates to close these gaps without manual effort:
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
Select “Yes” when prompted to automatically install security updates. Verify the configuration at /etc/apt/apt.conf.d/20auto-upgrades:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";
6. Additional Hardening Steps
After the essential steps above, implement these additional security measures to further lock down your VPS:
- Disable root login entirely: Set
PermitRootLogin noin sshd_config after verifying sudo access works correctly - Install and configure AIDE: The Advanced Intrusion Detection Environment monitors file integrity and alerts you to unauthorized changes in system binaries and configuration files. Initialize with
sudo aideinit - Set up logwatch: Receive daily email summaries of log activity so you can spot unusual patterns early:
sudo apt install logwatch - Audit listening services: Run
sudo ss -tulpnto list all services listening on network ports. Stop and disable any you do not recognize withsudo systemctl disable --now <service> - Harden kernel parameters: Disable IP forwarding (
net.ipv4.ip_forward=0), enable source address verification (net.ipv4.conf.all.rp_filter=1), and restrict ICMP redirects in/etc/sysctl.conf
Security Baseline Checklist
Run through this checklist after every new VPS deployment to ensure no step is missed:
- SSH key authentication configured and password login disabled
- Non-root sudo user created and tested with full sudo access
- UFW firewall enabled with default-deny incoming policy and only essential ports open
- Fail2ban installed and actively monitoring SSH on the non-default port
- Automatic security updates enabled via unattended-upgrades
- All listening services identified, documented, and unused services disabled
- Root SSH login disabled after sudo user verification
These seven steps take approximately 15 minutes to complete on a fresh VPS and eliminate the vast majority of common attack vectors — automated brute-force attacks, unpatched vulnerability exploits, and misconfigured services. Security is an ongoing process, not a one-time task. Review your configuration quarterly, subscribe to security advisories for the software you run, and periodically audit your VPS with tools like Lynis (sudo apt install lynis; sudo lynis audit system).
Check our VPS comparison table for providers with good performance specs and strong security features.




Leave a Reply
You must be logged in to post a comment.