SSH hardening: key-based auth, disabling root login, changing the default port
TL;DR: SSH access to a VPS is probed continuously by automated bots scanning the entire internet for exposed servers on the default port 22, attempting common username/password combinations, most commonly targeting the root account specifically. Three changes address the overwhelming majority of this automated attack surface: switching from password authentication to key-based authentication (making a successful brute-force attempt cryptographically infeasible rather than merely difficult), disabling direct root login (forcing an attacker to also guess a valid non-root username), and changing the default SSH port (which does not stop a targeted attacker but eliminates the large majority of indiscriminate, automated scanning traffic that specifically checks port 22 by default).
Why SSH is probed constantly regardless of your server's size
Any VPS with SSH enabled on the standard port is subject to continuous, automated, indiscriminate scanning by botnets sweeping the entire IPv4 address space looking for exposed SSH services, similar in nature to the WordPress login brute-forcing covered in our dedicated wp-admin guide, and this activity has nothing to do with your specific server's size or perceived importance; a brand-new VPS with no meaningful content on it will still see login attempts within hours of being provisioned. Treating this as background noise rather than evidence of specific targeting is accurate, but the defenses below remain genuinely necessary regardless, since the goal is resilience against this constant automated activity, not a response to being specifically singled out.
Key-based authentication: the most important change
Password authentication relies on a secret string that can, given enough attempts, eventually be guessed or brute-forced, particularly if the password is not genuinely strong and unique. Key-based authentication instead relies on a cryptographic key pair, a private key kept securely on your own machine and a corresponding public key placed on the server, where successful authentication requires possessing the specific private key, a cryptographically infeasible thing to brute-force given the key lengths in standard use, structurally eliminating the entire category of password-guessing attacks regardless of how many attempts an attacker makes. Setting this up involves generating a key pair, copying the public key to the server's authorized keys configuration, and then disabling password authentication entirely in the SSH server's configuration, at which point only a client possessing the correct private key can authenticate at all.
Disabling root login
The root account has unrestricted administrative access to the entire server, making it the single highest-value target for any attacker attempting to gain access, and it is also a predictable, known username that does not need to be separately guessed, unlike a custom account name. Disabling direct root login (typically via a specific SSH configuration setting) forces any legitimate administrative access to go through a separate, non-root user account first, with elevated privileges obtained through a separate, explicit mechanism (like sudo) after logging in, meaning an attacker attempting to target root specifically finds that direct path closed entirely, adding a meaningful additional barrier beyond just the key-based authentication requirement alone.
Changing the default port
SSH's default port, 22, is precisely what the overwhelming majority of automated, indiscriminate scanning specifically checks, since scanning every possible port on every possible IP address across the internet is considerably more resource-intensive for an attacker than simply checking the well-known default port everywhere. Changing to a non-standard port does not provide meaningful protection against a genuinely targeted, motivated attacker who would simply perform a full port scan of your specific server, but it does substantially reduce the volume of indiscriminate, automated attack traffic your server receives day to day, since most of that traffic is specifically, exclusively checking port 22 and will simply move on without ever discovering your server's SSH service on a different port at all.
A hardening checklist in priority order
Generate and configure key-based authentication first, and specifically confirm it is working correctly (successfully logging in via key) before disabling password authentication, since disabling password auth before confirming key-based access works correctly risks locking yourself out entirely. Disable direct root login, ensuring you have a properly configured non-root user with appropriate sudo access first. Change the default SSH port to a non-standard value, updating your own client configuration and any firewall rules to match. Confirm each change individually, testing actual access after each step, rather than applying all three simultaneously without verification, given how consequential a lockout from your own server would be.
Additional hardening worth considering
Rate limiting or fail2ban (covered in more depth in our dedicated fail2ban guide), automatically blocking an IP address after a defined number of failed authentication attempts, a complementary layer beyond key-based authentication specifically useful for reducing the sheer volume of connection attempts hitting your server. IP allowlisting, covered in the broader context of our dedicated guide, if your own access originates from a small, stable, predictable set of locations, restricting SSH access entirely to those specific IPs. Two-factor authentication for SSH, an additional layer beyond key-based authentication for particularly high-security requirements, requiring both the correct private key and a time-based code for successful login.
A comparison table
| Hardening measure | What it protects against | Protects against a targeted attacker? |
|---|---|---|
| Key-based authentication | Password brute-forcing and guessing | Yes, structurally eliminates this attack category |
| Disabled root login | Direct targeting of the highest-value account | Partially, forces an additional guessing step |
| Changed default port | Indiscriminate, automated scanning volume | No, a targeted attacker will find the actual port |
| fail2ban/rate limiting | Repeated automated connection attempts | Partially, slows and limits repeated attempts |
FAQs
Will I lock myself out if I disable password authentication incorrectly?
This is a genuine risk worth taking seriously; always confirm key-based authentication is working correctly in a separate, still-open session before disabling password authentication, and keep your hosting provider's own console/recovery access method available as a fallback in case something is misconfigured.
Do I need a different SSH key for every server I manage?
You can reasonably use the same key pair across multiple servers you personally manage, though using separate keys for genuinely different security contexts or when sharing access with different collaborators is a reasonable additional practice for more complex, multi-person environments.
Is changing the SSH port alone sufficient security, without the other measures?
No, as covered above, a port change alone only reduces indiscriminate automated scanning volume and provides no protection against a genuinely targeted attacker who performs an actual port scan of your specific server; it should be treated as one complementary layer, not a substitute for key-based authentication and disabled root login.
Can I still use a password as a backup in case I lose my SSH key?
This defeats much of the security benefit of disabling password authentication in the first place; a safer backup approach is securely storing a backup copy of your private key in a genuinely secure location (a password manager, an encrypted backup) rather than re-enabling password authentication as a fallback.
Does my hosting provider need to support these changes, or can I configure them myself?
On a VPS with root access, you can configure all of these directly yourself through standard SSH server configuration; on more restrictive managed hosting without direct server access, some of these settings may not be available to configure independently, worth confirming with your specific provider.
How do I know if my server is currently receiving SSH attack attempts?
Checking your server's authentication logs directly shows failed login attempts, typically revealing a steady, ongoing stream of automated attempts even on a server that has never been specifically, individually targeted, confirming the background-noise nature of this activity discussed above.
Should I use ED25519 or RSA for my SSH key type?
ED25519 is generally considered the current, more modern recommended key type, offering strong security with better performance characteristics than traditional RSA keys, though RSA keys at a sufficiently long length remain a secure, widely supported option as well if your specific tooling has any compatibility considerations favoring it.
Conclusion
Key-based authentication, disabled root login, and a changed default SSH port together address the overwhelming majority of automated SSH attack traffic any internet-facing VPS receives continuously, each targeting a different specific aspect of the typical automated attack pattern. None require advanced security expertise to implement, though confirming each change works correctly before moving to the next, particularly before disabling password authentication, is essential given how consequential an accidental lockout from your own server would be.
HostCloud's VPS plans give you full root access to implement these hardening measures directly, and our support team can help walk through the setup process safely if you are configuring SSH hardening for the first time. See VPS plans at https://hostcloud.in.