{"id":359,"date":"2026-10-07T06:14:37","date_gmt":"2026-10-07T13:14:37","guid":{"rendered":"https:\/\/blog.canutethegreat.com\/index.php\/2026\/10\/07\/ssh-hardening-beyond-disable-root-login\/"},"modified":"2026-10-20T20:23:08","modified_gmt":"2026-10-21T03:23:08","slug":"ssh-hardening-beyond-disable-root-login","status":"publish","type":"post","link":"https:\/\/blog.canutethegreat.com\/index.php\/2026\/10\/07\/ssh-hardening-beyond-disable-root-login\/","title":{"rendered":"SSH hardening beyond “disable root login”"},"content":{"rendered":"\n

Part 1 of 4 in the Hardening a Linux server series.<\/em><\/p>\n\n\n\n

Every hardening guide starts with PermitRootLogin no<\/code>, and plenty of them stop there. That setting is fine. It’s also the least interesting thing about securing SSH, because an attacker who can log in as a sudo-capable user with a password has root anyway. The things that actually decide how exposed your SSH daemon is are how users prove who they are, how the server proves who it is, which crypto you still accept, and who is allowed to try at all.<\/p>\n\n\n\n

Start from what sshd is really doing<\/h2>\n\n\n\n
\"Sequence<\/figure>\n\n\n\n

Before changing anything, look at the effective configuration rather than the file. Distributions now ship Include \/etc\/ssh\/sshd_config.d\/*.conf<\/code> near the top of sshd_config<\/code>, and for most keywords sshd uses the first value it reads, not the last. I’ve watched people append PasswordAuthentication no<\/code> to the bottom of the main file while a cloud-init drop-in earlier in the include order said yes<\/code>, and the drop-in won.<\/p>\n\n\n\n

sudo sshd -T | grep -Ei 'passwordauth|kbdinteractive|permitroot|pubkeyauth|authenticationmethods'\nsudo sshd -T -C user=deploy,host=10.0.0.5,addr=10.0.0.5<\/code><\/pre>\n\n\n\n
The second form evaluates Match<\/code> blocks for a specific connection, which is the only sane way to test conditional rules. Put your own settings in a drop-in with a low number, like \/etc\/ssh\/sshd_config.d\/00-hardening.conf<\/code>, so they load first.<\/p>\n\n\n\n
Keys, and better keys<\/h2>\n\n\n\n
Passwords on an internet-facing sshd are a credential-stuffing target forever. Turn off both password paths, since keyboard-interactive will happily do password auth through PAM even when PasswordAuthentication<\/code> is off:<\/p>\n\n\n\n
PasswordAuthentication no\nKbdInteractiveAuthentication no\nPubkeyAuthentication yes\nPermitRootLogin no\nMaxAuthTries 3\nLoginGraceTime 20<\/code><\/pre>\n\n\n\n
(KbdInteractiveAuthentication<\/code> replaced ChallengeResponseAuthentication<\/code> in OpenSSH 8.7. Older configs use the old name, which is still accepted as an alias.)<\/p>\n\n\n\n
For user keys, Ed25519 is the default choice now. The bigger upgrade is hardware-backed keys. Since OpenSSH 8.2 you can generate ed25519-sk<\/code> keys that live on a FIDO2 token, so the private key file on disk is useless without the physical device and a touch:<\/p>\n\n\n\n
ssh-keygen -t ed25519-sk -O resident -O verify-required -C \"alice@laptop\"<\/code><\/pre>\n\n\n\n
verify-required<\/code> (OpenSSH 8.4+) demands a PIN as well as a touch. Malware on a laptop can steal an ordinary key file in a second. With an -sk<\/code> key it has to wait for the user to tap the token at the right moment, which is a much harder problem.<\/p>\n\n\n\n
Certificates instead of authorized_keys sprawl<\/h2>\n\n\n\n
The real weakness of plain public keys is lifecycle. authorized_keys<\/code> files accumulate keys from people who left two years ago, and nobody can say which key belongs to whom. OpenSSH has had its own certificate format since 5.4, and it’s underused. A CA signs a user’s public key with an identity, a list of principals and a validity window:<\/p>\n\n\n\n
ssh-keygen -s user_ca -I alice@example.com -n alice,deploy -V +8h id_ed25519.pub<\/code><\/pre>\n\n\n\n
The server trusts the CA rather than individual keys:<\/p>\n\n\n\n
TrustedUserCAKeys \/etc\/ssh\/user_ca.pub\nAuthorizedPrincipalsFile \/etc\/ssh\/principals\/%u\nRevokedKeys \/etc\/ssh\/revoked_keys<\/code><\/pre>\n\n\n\n
\/etc\/ssh\/principals\/deploy<\/code> lists which principals may log in as deploy<\/code>. Now offboarding is mostly automatic, because certificates expire in hours, and the -I<\/code> identity shows up in the auth log so you know which human used the shared account. Keep an emergency revocation path anyway (ssh-keygen -k<\/code> builds a key revocation list), and protect the CA key like the crown jewels it is, ideally in a hardware token or a signing service.<\/p>\n\n\n\n
Host certificates solve the other half. Sign host keys with ssh-keygen -h<\/code>, add one @cert-authority *.example.com<\/code> line to clients’ known_hosts<\/code>, and the “authenticity of host can’t be established” prompt that everyone trains themselves to click through goes away. Trust on first use is a bet that the first connection wasn’t intercepted. Certificates remove the bet.<\/p>\n\n\n\n
Prune the crypto, but don’t fight the defaults<\/h2>\n\n\n\n
Modern OpenSSH defaults are good, and hand-written cipher lists copied from 2016 blog posts are often worse than the defaults they replace. OpenSSH 8.8 already disabled ssh-rsa<\/code> signatures using SHA-1. OpenSSH 9.0 made the hybrid post-quantum sntrup761x25519-sha512@openssh.com<\/code> key exchange the default, and 10.0 moved to mlkem768x25519-sha256<\/code>.<\/p>\n\n\n\n
Where explicit lists still pay off is when a specific weakness lands. Terrapin (CVE-2023-48795) was a prefix-truncation attack against the SSH transport that worked when chacha20-poly1305@openssh.com<\/code>, or a CBC cipher paired with an encrypt-then-MAC MAC, was negotiated. The fix was “strict kex” in OpenSSH 9.6, which needs both sides patched. Until clients caught up, removing the affected algorithms was a reasonable stopgap. Audit what you expose with ssh-audit rather than guessing:<\/p>\n\n\n\n
ssh-audit -p 22 server.example.com<\/code><\/pre>\n\n\n\n
Decide who gets to try<\/h2>\n\n\n\n
Authentication strength matters less if most accounts can’t authenticate at all. An allowlist is short and readable:<\/p>\n\n\n\n
AllowGroups ssh-users\nAllowTcpForwarding no\nAllowAgentForwarding no\nAllowStreamLocalForwarding no\nX11Forwarding no\n\nMatch Group ssh-admins Address 10.20.0.0\/16\n    AllowTcpForwarding yes\n\nMatch User backup\n    ForceCommand \/usr\/local\/bin\/backup-receive\n    PermitTTY no<\/code><\/pre>\n\n\n\n
Forwarding is how an SSH foothold turns into a pivot into the rest of the network, so default it off and turn TCP forwarding back on only for admins coming from the internal range. There’s also DisableForwarding yes<\/code> (OpenSSH 7.4+), which kills every kind of forwarding in one line, but it overrides the individual switches, so a Match<\/code> block can’t selectively re-enable one of them without also setting DisableForwarding no<\/code> there. Explicit switches are easier to reason about.<\/p>\n\n\n\n
Network placement still matters. Port knocking and moving sshd to port 2222 cut log noise, nothing more. Putting sshd behind a VPN or a bastion, or at least restricting port 22 to known address ranges at the firewall, actually shrinks who can reach the parser. And the parser has had bad days. regreSSHion (CVE-2024-6387) was a signal-handler race in sshd on glibc Linux that allowed unauthenticated remote code execution, affecting OpenSSH 8.5p1 through 9.7p1 until 9.8p1 fixed it. The temporary mitigation was LoginGraceTime 0<\/code>, which trades RCE risk for an easy connection-exhaustion DoS. The xz backdoor (CVE-2024-3094) showed that sshd’s attack surface includes whatever libraries your distribution links into it. Nobody’s config file would have stopped either of those. Reachability would have.<\/p>\n\n\n\n
OpenSSH 9.8 also added PerSourcePenalties<\/code>, which is on by default and makes sshd refuse connections for a while from addresses that repeatedly fail auth or crash a child. It’s a built-in, rough fail2ban.<\/p>\n\n\n\n
Log enough to answer questions later<\/h2>\n\n\n\n
Set LogLevel VERBOSE<\/code>. At that level sshd logs the fingerprint of the key that authenticated each session, and for certificates the key ID and serial. Without it, “which key did this login use?” has no answer. Part 3 of this series covers auditd and shipping those logs somewhere an intruder can’t edit them.<\/p>\n\n\n\n
What I’d actually do on a new server, in order: allowlist users, kill passwords, move people to certificates, keep forwarding off, limit reachability, and patch sshd quickly when the next CVE lands. Disabling root login comes for free along the way.<\/p>\n\n\n\n
Other parts of the Hardening a Linux server series: Part 2: Least privilege with systemd sandboxing<\/a>, Part 3: auditd and what to log<\/a>, Part 4: Patching without fear<\/a>.<\/em><\/p>\n\n","protected":false},"excerpt":{"rendered":"
Part 1 of 4 in the Hardening a Linux server series. Every hardening guide starts with PermitRootLogin no, and plenty of them stop there. That setting is fine. It’s also the least interesting thing about securing SSH, because an attacker who can log in as a sudo-capable user with a password has root anyway. The […]<\/p>\n","protected":false},"author":1,"featured_media":360,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22,21],"tags":[87,88,85,84,86],"class_list":["post-359","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","category-security","tag-fido2","tag-hardening-a-linux-server-series","tag-openssh","tag-ssh","tag-ssh-certificates"],"_links":{"self":[{"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/posts\/359","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/comments?post=359"}],"version-history":[{"count":1,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/posts\/359\/revisions"}],"predecessor-version":[{"id":392,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/posts\/359\/revisions\/392"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/media\/360"}],"wp:attachment":[{"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/media?parent=359"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/categories?post=359"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/tags?post=359"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}