SSH is your server’s front door, and on the Internet doors get tried thousands of times a day. Just spin up a new machine and check the logs a few hours later: you will see login attempts from half the world trying common usernames and dictionary passwords. It is not personal, it is automated.
The good news is that three measures remove most of the risk, and none of them is complicated.
First: keys instead of passwords
An SSH key is a pair of files: a public one that lives on the server and a private one that never leaves your computer. The advantage is not just length, it is that the secret never travels: there is nothing an attacker can brute-force their way into guessing.
Generate your pair with ssh-keygen -t ed25519, copy the public one to the server, verify you can log in with it, and only then disable password authentication. That order matters: disabling before verifying is the quickest way to lock yourself out of your own machine.
If you keep passwords, do it properly
Sometimes a password is necessary, for instance because you need to get in from a web console without your key. In that case, two rules: make it long, twenty characters or more, and keep exotic symbols out. Remote consoles map characters according to the client’s keyboard layout, so a symbol that needs the shift key can reach the server as something else. It is a classic source of frustration: you type the correct password and the server receives a different one.
Second: an alternative port
Changing port 22 for another is not real security, and anyone telling you otherwise is overselling it. A port scan finds your SSH on any port within seconds.
But it does bring two concrete benefits. The first is that it drastically cuts the noise: the automated bots sweeping the Internet only try 22, so your logs go from thousands of daily attempts to almost none, and when a real one shows up you will see it.
The second is more practical than it sounds: some corporate networks and some transit carriers filter port 22 as policy. Having an alternative port open gives you a path when the standard one does not get through. Our recommendation is to keep both.
Third: evict whoever insists
Install fail2ban or an equivalent. It watches the logs, and when an address fails several times in a row it temporarily blocks it at the firewall. It is a cheap measure that stops slow brute-force attacks dead, the ones trying three passwords an hour to stay under the radar.
The detail almost nobody checks
Everything above appears in any guide. This is what gets forgotten: review who can actually log in.
Every account with SSH access is one more door. The account you created for a developer who no longer works with you, the user of an application you no longer run, the public key of a laptop you lost. An sshd -T shows you the server’s effective policy, and reviewing each user’s authorized keys file takes five minutes.
Fewer users, less surface. And disable direct root login with a password: log in as your user and escalate with sudo, so there is a trail of who did what.
A warning about testing
Before reloading your SSH configuration, always run sshd -t to validate the syntax. And if you are working remotely, open a second session before applying changes: if something goes wrong, that open session is your lifeline while you fix it.
How we deliver it
Our VPS in Andorra ship with root access, alphanumeric passwords that do not break in web consoles, and two SSH ports configured out of the box precisely because of the transit filtering issue. And since any hardening goes wrong occasionally, the backup addon lets you roll back in minutes.