VPS Root Access in Practice: SSH Hardening, Firewalls, and Daily Administration

Root access is the defining feature that separates VPS hosting from shared hosting. With root privileges you control every layer of the server — kernel parameters, installed packages, firewall rules, and service configuration. That power comes with responsibility: an unhardened root login is the fastest way to lose a server. This article walks through the practical hardening and administration tasks every VPS owner should run.

Before provisioning, check what you are getting for your money — you can compare VPS providers on our comparison table to see which ones give you true root access and modern hardware.

Harden SSH Before Anything Else

The default configuration on most VPS images allows password-based root login over port 22, which is a prime target for automated brute-force attacks. Tighten it immediately:

# Edit /etc/ssh/sshd_config
# Set:
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes
Port 2222   # move off the default

sudo systemctl restart sshd

Always use SSH key pairs instead of passwords: generate a key on your local machine and copy the public key to the server with ssh-copy-id before disabling password auth, so you never lock yourself out:

# On your local machine
ssh-keygen -t ed25519 -a 100
ssh-copy-id -p 2222 admin@your-vps-ip

Ed25519 keys are shorter, faster to verify, and considered stronger than RSA at equivalent lengths. Keep the private key on your laptop or a hardware token, never on the server itself. If you manage several servers, add a passphrase to the key and use ssh-agent so you only type it once per session — that way a stolen laptop does not automatically expose every box you administer.

Create a Sudo User

Operating as root for routine tasks is dangerous — one mistyped command can destroy the system. Create a regular user with sudo privileges and use it for daily work:

sudo adduser admin
sudo usermod -aG sudo admin
# Test the new account:
su - admin
sudo whoami   # should print: root

Set Up the Firewall with UFW

Uncomplicated Firewall (UFW) provides a simple interface over iptables and is the fastest way to get a sane default-deny posture:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp   # your custom SSH port
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Automate Security Patches

Unpatched software is the number one attack vector on VPS instances. On Debian and Ubuntu, unattended-upgrades keeps security patches flowing without manual intervention:

sudo apt update && sudo apt upgrade -y
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
# Allow automatic reboots after kernel updates:
sudo sed -i 's/Unattended-Upgrade::Automatic-Reboot "false"/Unattended-Upgrade::Automatic-Reboot "true"/' /etc/apt/apt.conf.d/50unattended-upgrades

Monitor Resources and Block Brute Force

Real-time monitoring catches problems before users do. Install htop, nmon, and iotop to watch CPU, memory, and disk I/O, and pair them with fail2ban to block repeated SSH login attempts:

sudo apt install htop nmon iotop fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

fail2ban watches log files for repeated failures and temporarily bans offending IPs via the firewall. The default jail covers sshd, and adding jails for nginx and apache takes one small config block each. Tune the bantime up from the default 10 minutes to an hour or more; legitimate users who typo a password can wait out an hour, while bots rarely come back to the same address. Combine this with the earlier SSH hardening and most brute-force traffic never even reaches your sshd process.

Build a Minimal Backup Routine

Never rely on a single copy of your data. A small cron-driven rsync script covers most VPS setups and costs nothing:

# /usr/local/bin/backup.sh
#!/bin/bash
rsync -az --delete /var/www/ backup@remote:/backups/www/
rsync -az --delete /etc/ backup@remote:/backups/etc/
# Add to crontab: 0 3 * * * /usr/local/bin/backup.sh

For databases, add a logical dump before the rsync step so you can restore to a different server or MySQL version. The dump does not need to be fancy — a plain mysqldump piped to a dated file is enough for most small deployments. The two rules that matter are: store backups off-box (a second VPS, object storage, or your own machine), and test a restore at least once a quarter. An untested backup is a guess, and the whole point of the routine is to remove guesswork from disaster recovery.

The Daily Administration Loop

• Check free memory and disk usage first thing: free -h and df -h.
• Review fail2ban-client status sshd for blocked IPs.
• Run apt update && apt list –upgradable to spot pending patches.
• Verify backups ran: check the remote backup timestamps.
• Watch %steal in top if performance feels inconsistent.

These practices form the foundation of safe VPS administration. Once the server is hardened, monitored, and backed up, you can deploy applications with confidence. When choosing where to run it, see the full specs and pricing of providers that offer full root access.

InterServer’s unmanaged VPS line gives you unrestricted root access on NVMe storage at a flat, predictable price — view their VPS plans here.