{"id":995,"date":"2026-08-28T23:52:45","date_gmt":"2026-08-28T23:52:45","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=995"},"modified":"2026-10-16T22:03:07","modified_gmt":"2026-10-16T22:03:07","slug":"ssh-security-best-practices-vps","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/ssh-security-best-practices-vps\/","title":{"rendered":"Hardening SSH on a VPS: Bastion Architecture, Key Attribution and Revocation That Scales"},"content":{"rendered":"\n

SSH is the single most attacked service on any internet-facing VPS. Every public IPv4 address receives thousands of authentication attempts per day, and most of those attempts target root<\/code> with a short password list. Hardening SSH properly is not about setting PasswordAuthentication no<\/code> and calling it done \u2014 it is about building an access architecture that scales, that lets you attribute every login to a human, and that lets you revoke access in seconds when someone leaves. This guide covers the model and the measurement commands behind it.<\/p>\n\n\n

If you are still choosing a host, review the VPS comparison table on our main site<\/a> \u2014 provider differences in IPv6 support, console access and snapshot tooling directly affect how you recover a VPS when SSH is misconfigured. Once you have a box, the rest of this article is about making that access plane defensible.<\/p>\n\n\n

Start by Measuring What Is Actually Hitting Your SSH Port<\/h2>\n\n\n

Before changing a single line of sshd_config<\/code>, quantify the noise. This tells you whether you are facing distributed credential stuffing, a targeted campaign, or simple background scanning.<\/p>\n\n\n

journalctl -u ssh --since \"24 hours ago\" | grep -c \"Failed password\"\nss -tn state established '( sport = :22 )'\nauth={}; zgrep -h \"Failed password\" \/var\/log\/auth.log* 2>\/dev\/null | awk '{print $1}' | sort | uniq -c | sort -rn | head<\/code><\/pre>\n\n\n
The first command gives you a 24-hour failure count. The second shows who is legitimately connected right now. The third ranks source IPs. If you see tens of thousands of failures from diverse networks, that is automated scanning and rate limiting plus key-only auth will eliminate essentially all of it.<\/p>\n\n\n
Install sshd<\/code> connection accounting so you always know the source: set LogLevel VERBOSE<\/code> to record key fingerprints per login. Without that, all sessions look identical and you cannot attribute activity to a person or a key.<\/p>\n\n\n
Move From Passwords to Keys, Then From Keys to Certificates<\/h2>\n\n\n
Password authentication on a public VPS is indefensible. Keys are the baseline, but a fleet of long-lived keys pasted into authorized_keys<\/code> files is its own problem: you cannot tell which key belongs to whom, and revocation means editing every host. A bastion with short-lived, signed certificates solves attribution and revocation at once.<\/p>\n\n\n