SSH Hardening Checklist for VPS: 8 Practical Steps

A common weakness on internet-facing VPS instances is leaving password-based SSH authentication exposed to automated login attempts. Disabling password authentication, restricting SSH access, using a dedicated administrative account, and applying firewall and monitoring controls can significantly reduce SSH-related attack exposure. This checklist walks through eight practical SSH hardening steps that address the most frequent configuration gaps.

Common SSH-related exposure patterns on public VPS. Illustrative examples only, not measured statistics.

Why password authentication remains a concern

Automated scanners continuously probe port 22 across the public internet. They try common usernames such as root, ubuntu, admin and deploy, often paired with leaked or weak passwords. Internet-facing SSH services are routinely scanned, and password-based authentication remains a documented security concern. Shadowserver, for example, flags exposed SSH instances that advertise password authentication.

Key-based authentication changes the equation. An attacker needs an accepted credential rather than a guessable password. For internet-facing SSH, disabling password authentication is one of the highest-impact baseline hardening changes you can make. Ubuntu documentation also recommends disabling password authentication once key-based access is available.

The 8 practical SSH hardening steps

Follow these steps in order. Keep your existing SSH session open and keep the provider console available until a new key-based login works. Never close the current session until a second session succeeds.

1. Create a dedicated sudo user

adduser deploy
usermod -aG sudo deploy

Work as a named user with sudo privileges. Attackers commonly target the root account because it exists on every Linux system.

2. Generate an Ed25519 key pair on your local machine

ssh-keygen -t ed25519 -a 100 -C "you@yourdomain"

Ed25519 is a modern, widely supported SSH key type and a good default for new keys. The -a 100 option increases the KDF work factor that protects the private key with its passphrase. Protect the private key with a passphrase and never copy it to the server.

3. Deploy the public key and test login

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@YOUR_VPS_IP
ssh deploy@YOUR_VPS_IP

Confirm key-based login works in a new terminal before changing server-side authentication settings.

4. Disable password authentication for SSH hardening

Prefer a drop-in file so package updates do not overwrite your changes:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

For a standard single-user VPS where you want public-key-only SSH:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey

This is intentionally strict and can interfere with MFA, keyboard-interactive, PAM or enterprise authentication. Adjust if those features are required.

sudo sshd -t && sudo systemctl reload ssh
sudo sshd -T | grep -E 'passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|authenticationmethods|permitrootlogin'

OpenSSH uses the first value set for most directives, so verify the effective configuration if other snippets exist. Keep your current session open until a new login succeeds.

5. Disable direct root SSH login

In the same file add:

PermitRootLogin no

Disabling direct root SSH login reduces the impact of a compromised root credential and encourages use of a named sudo account.

Configure UFW, Fail2Ban and monitoring

With key-only authentication and root login disabled, add network filtering, rate limiting and observability. Configure UFW before Fail2Ban when you use the UFW ban action, because that action requires UFW to be enabled.

6. Configure UFW basics

UFW provides a simple default-deny posture. Allow only the ports you need.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Replace 22 with your actual SSH port if you already changed it.

To restrict SSH to a trusted office or VPN range, first confirm reachability, then:

sudo ufw delete allow 22/tcp
sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp

Verify the new rule before closing sessions. Enable logging:

sudo ufw logging on

7. Install and configure Fail2Ban for SSH hardening

Fail2Ban detects repeated authentication failures and temporarily blocks offending IP addresses. With key-only authentication it is a secondary control, but it still reduces repeated connection attempts.

sudo apt update && sudo apt install fail2ban -y
sudo nano /etc/fail2ban/jail.local

For modern systemd-based Ubuntu and Debian systems prefer the systemd backend:

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
banaction = ufw

[sshd]
enabled  = true
port     = ssh
filter   = sshd
backend  = systemd
maxretry = 3

If your system still writes SSH events to /var/log/auth.log, you can set logpath = /var/log/auth.log instead. Do not assume that file exists on every current installation.

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

UFW must already be enabled for banaction = ufw to take effect.

Monitor authentication and firewall activity

8. Decide what to monitor after SSH hardening

Watch these sources:

• sudo journalctl -u ssh.service for accepted public-key logins. On systems that still use traditional auth logs, /var/log/auth.log may also contain relevant entries.
• fail2ban-client status sshd for banned addresses.
• UFW logs (after ufw logging on) for denied attempts on unexpected ports.

For a small personal VPS without centralized monitoring, a weekly manual review is a reasonable minimum. Production or higher-value systems should use automated alerting and more frequent review. Unexpected successful key logins from unfamiliar IPs are high-signal events.

What this looks like at 2 a.m. after SSH hardening

You notice unusual activity or simply review the logs. You see a burst of failed password attempts from many source IPs. Because password authentication is disabled, password guessing cannot authenticate through SSH. Fail2Ban has already banned the noisiest sources. An attacker would instead need an accepted authentication credential or another vulnerability or access path. That is the practical difference these controls create for the SSH surface.

Optional next layers

Once the core eight steps are in place you can consider:

• Restricting SSH by source IP or to a private VPN interface (WireGuard, Tailscale, or similar) so the SSH service is not directly reachable from the public internet
• Restricting which accounts can connect with AllowUsers or AllowGroups (useful on multi-user servers)
• Adding FIDO2-backed SSH keys for higher-value accounts
• Changing the SSH port to reduce commodity scanner noise (noise reduction only, not a substitute for authentication controls)
• Disabling unnecessary forwarding options if they are not required

These refinements add defence in depth. They do not replace the foundation of key-only authentication, disabled root login, firewalling and monitoring.

Why Rabisu for the underlying VPS

You can apply this entire checklist on any Linux VPS that gives you full control of the operating system. Rabisu VPS plans provide full root access, giving you direct control over SSH configuration, firewall rules, packages, users and other server-level security settings. Multiple global locations let you place the server close to your users or game community when latency matters.

If you are also running containers, the same hardened host base works with Docker. See the companion guide on running Docker on a VPS for resource limits and compose patterns that sit on top of this foundation. The same applies when you later add Discord bots or other long-running services.

Quick Answers

Commands and configuration examples target current Ubuntu and Debian defaults. Always test in a non-production environment or keep console access available before applying changes to a live server. Verify effective settings with sshd -T after configuration changes.