{"id":2011,"date":"2026-07-08T12:16:00","date_gmt":"2026-07-08T11:16:00","guid":{"rendered":"https:\/\/www.halkynconsulting.co.uk\/a\/?p=2011"},"modified":"2026-07-23T17:50:29","modified_gmt":"2026-07-23T16:50:29","slug":"ssh-hardening","status":"publish","type":"post","link":"https:\/\/www.halkynconsulting.co.uk\/a\/2026\/07\/ssh-hardening\/","title":{"rendered":"SSH Hardening: Locking Down Remote Access"},"content":{"rendered":"

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.<\/p>\n

Why SSH draws attention<\/h2>\n

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.<\/p>\n

Prefer keys to passwords<\/h2>\n

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<\/code>. 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.<\/p>\n

Control who can log in<\/h2>\n

Not every account needs remote access, and the root account needs it least of all. Set PermitRootLogin no<\/code> 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<\/code> or AllowGroups<\/code>, 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.<\/p>\n

Harden the configuration<\/h2>\n

Several settings in sshd_config<\/code> repay a few minutes each:<\/p>\n