Blog

Every internet-facing Linux server sees SSH login attempts within minutes of coming online. Most are automated, tireless and utterly indiscriminate. SSH hardening is the practice of shrinking that exposure until a working login becomes very hard to obtain. None of it is exotic. Rather, it is a set of sensible defaults that too many builds still skip. Get them right once, and you close the door that most opportunistic attacks rattle first.

Why SSH draws attention

SSH is powerful, which is precisely why attackers target it. A single valid credential grants a remote shell, and from there an intruder can pivot across the network, persist quietly or steal data. Because so many systems run the service, bulk scanning for weak passwords costs almost nothing and never stops. The service is simply too useful to leave loosely defended. Consider the economics from the attacker’s side. One script can probe thousands of hosts an hour, so any server with a weak password is eventually found. Therefore the aim is not to hide SSH, but to make each of its defences genuinely count.

Prefer keys to passwords

Password authentication is the weakest common link. People reuse passwords, choose guessable ones, and rarely notice a slow brute-force attempt against them. Public-key authentication removes that entire class of problem in one step. In practice you generate a key pair, place the public half on the server, and protect the private half with a strong passphrase. The private key never leaves your own machine, which is the entire point. Once keys work reliably, turn password authentication off with PasswordAuthentication no. As a result, a stolen password becomes useless on its own. Keys also scale better in a team. You can revoke a single compromised key without forcing a reset on everyone else who still needs access.

Control who can log in

Not every account needs remote access, and the root account needs it least of all. Set PermitRootLogin no so that administrators sign in as themselves and then escalate, which also preserves a clear audit trail of who did what. Furthermore, restrict access explicitly with AllowUsers or AllowGroups, naming only the accounts that genuinely require it. In effect, this turns SSH from an open front door into a short, known guest list. Where several administrators share one system, named accounts matter even more, because a shared login quietly destroys any accountability after an incident.

Harden the configuration

Several settings in sshd_config repay a few minutes each:

• Modern algorithms only. Disable legacy ciphers and MACs so that weak cryptography cannot be negotiated.
• Idle timeouts. Use ClientAliveInterval and ClientAliveCountMax to close forgotten sessions.
• Fewer attempts. Cap tries with MaxAuthTries and limit concurrency with MaxSessions.
• No empty passwords. Confirm that PermitEmptyPasswords no appears explicitly.

After every change, test with a second session before you close the first. Otherwise a single typo in the configuration can lock you out of the very machine you are trying to secure. None of this is hard, yet the defaults rarely arrive this way, so someone has to make the changes on purpose.

Slow the attackers down

Even a key-only server benefits from throttling the background noise. Tools such as fail2ban watch the logs and temporarily block addresses that fail repeatedly, which cuts brute-force traffic to a trickle within minutes. Similarly, restricting SSH to known source networks at the firewall removes most of the internet from the conversation altogether. Where practical, place administrative access behind a bastion host or a VPN, so that the service is never exposed directly to the open internet. In addition, forwarding logs to a separate host means an intruder who lands on the server cannot quietly erase the trail showing how they arrived.

Watch, and keep watching

Hardening is never a one-off exercise. Log both successful and failed logins, and actually read them, because a sudden shift in the pattern is often the first sign of trouble. Alerts on repeated failures turn a quiet log into a timely warning. Review the authorised keys periodically, and remove any that still belong to people who have long since moved on. The National Cyber Security Centre also publishes practical guidance on secure system administration that complements these steps well.

Where to start with SSH hardening

Pick one server, and work steadily through the list: keys, no root, a named user list, a tidy configuration, and log-based blocking. Confirm each change from a fresh session before you move on to the next. Then capture the result as a template, so that every new build starts hardened rather than being patched up long afterwards. Small, repeatable steps, applied to one server and then templated across the rest, beat a single heroic effort that nobody can reliably repeat later.

Halkyn Consulting helps organisations build and review secure Linux estates, from a single server to a fleet-wide standard. If you would like support hardening your systems, get in touch with our team.