SSH Hardening Best Practices: Key-Only Authentication and a Locked-Down sshd on Your VPS

SSH is the most attacked service on the internet. Within hours of provisioning a VPS with default settings, authentication logs show thousands of failed login attempts from botnets scanning port 22 and spraying common passwords. The defaults are exactly what attackers want: password authentication enabled, root allowed to log in directly, and no rate limiting. Hardening SSH is a one-time task that takes about fifteen minutes and eliminates entire classes of attacks before they reach your application. This guide covers the order of operations that matters.

The steps below assume a fresh VPS with a root login and an IP you control from a fixed location. If you have not chosen a provider yet, compare plans side by side — hosts that include native DDoS filtering and a dedicated IPv4 address make SSH hardening noticeably more effective, because attackers cannot hide your entry point behind a shared NAT.

Step 1: Move to Key-Based Authentication

Ed25519 keys are fast, short, and considered secure. Generate one on your local machine and copy it to the server:

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/vps_ed25519
ssh-copy-id -i ~/.ssh/vps_ed25519.pub root@YOUR_SERVER_IP

Verify that the key works end to end (ssh -i ~/.ssh/vps_ed25519 root@YOUR_SERVER_IP) before disabling passwords. Keep the private key on a machine with disk encryption, and consider adding a passphrase plus ssh-agent so the key is not usable if the laptop is stolen. Add IdentitiesOnly yes to ~/.ssh/config for the host so ssh does not try every key in your agent and trip MaxAuthTries on the server.

Step 2: Lock Down sshd_config

Edit /etc/ssh/sshd_config and apply these settings, then create a non-root user for daily work:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
MaxSessions 4
LoginGraceTime 20
AllowUsers deploy
# optional: restrict to a single port and listen address
# Port 2222
# ListenAddress 10.0.0.5

Create the user with adduser deploy, add your public key to /home/deploy/.ssh/authorized_keys, and grant sudo with usermod -aG sudo deploy. Then lock down the file permissions that OpenSSH is strict about: chmod 700 /home/deploy/.ssh and chmod 600 /home/deploy/.ssh/authorized_keys — if the key file is world-readable or the directory is group-writable, sshd silently ignores it. Finally run sshd -t to validate the config, and reload with systemctl reload ssh. Always keep a second terminal session open when testing — if you lock yourself out, you can still revert from the other session.

Step 3: Rate-Limit SSH at the Firewall

Key-only authentication already stops password brute force, but rate limiting also throttles connection floods that can exhaust sshd child processes. You do not need a separate daemon for this — nftables (the default firewall on Debian 12 and Ubuntu 22.04+) can limit new SSH connections natively:

table inet filter {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        tcp dport 22 ct state new limit rate 4/minute burst 8 accept
        tcp dport 22 ct state new drop
        tcp dport 80,443 accept
    }
}

This accepts at most four new SSH connections per minute with a burst of eight — plenty for legitimate use, brutal for scanners. The same table can also drop invalid packets (ct state invalid drop) and log rejected attempts to a dedicated chain. If you prefer a ready-made tool, Fail2ban wraps this idea with per-IP banning, but the native rules above need no extra service and survive reboots via nft list ruleset > /etc/nftables.conf.

Step 4: Optional Two-Factor Authentication

For root access to production servers, add a second factor with the PAM Google Authenticator module: install libpam-google-authenticator, run google-authenticator as the user, and add auth required pam_google_authenticator.so to /etc/pam.d/sshd together with AuthenticationMethods publickey,keyboard-interactive in sshd_config. The result is key-plus-TOTP authentication — even a stolen private key is useless without the phone.

Step 5: Watch the Authentication Log

Harden SSH once, on every server, before anything else touches the network. The full sequence — keys, locked-down sshd, native rate limiting, optional 2FA, and log monitoring — takes minutes and removes the most common entry point attackers use. If you are evaluating hosts for a new deployment, our comparison table covers which providers include DDoS protection and managed firewalls on top of the base specs.

Ready to put this into practice? InterServer’s VPS plans give you full root access with a dedicated IP from the first month, so you can apply exactly this hardening without platform restrictions.