CoursesLinux hardeningAccess hardening

SSH hardening

Keys only, no root, minimal exposure.

Intermediate14 min · lesson 1 of 16

SSH is the front door to almost every Linux server, which makes it the single most attacked service on the internet — automated bots hammer port 22 with password guesses continuously. So SSH hardening is where server security starts, and the highest-value change is the simplest: turn off password authentication entirely and accept only cryptographic keys. A key cannot be brute-forced the way a password can, so the moment you go keys-only, the entire password-guessing threat disappears.

/etc/ssh/sshd_config.d/10-hardening.conf
PasswordAuthentication no # keys only — the single biggest win
PermitRootLogin no # no direct root login; log in as a user, then sudo
PubkeyAuthentication yes
KbdInteractiveAuthentication no # close the other password-ish paths
X11Forwarding no
AllowGroups ssh-users # only members of this group may SSH in at all

No root login, restrict who can connect

Two more essentials. PermitRootLogin no forces everyone to log in as a named user and then escalate with sudo — restoring the attribution the essentials course insisted on (a shared root login destroys your audit trail). And AllowGroups (or AllowUsers) restricts SSH access to an explicit allowlist, so even a valid account outside that group cannot connect. Combined, an attacker now needs a specific user’s private key AND membership in the allowed group AND then a second step to reach root.

Apply changes safely

Editing sshd_config is one of the few changes that can lock you out of your own server, so apply it carefully: validate the config with sshd -t before restarting, and keep your current session open while you test a new connection in a second terminal. If the new settings break your access, you still have the working session to fix them. Never restart sshd with a broken config and no fallback.

terminal
$ sudo sshd -t # validate config — no output means OK
$ sudo systemctl reload ssh # apply
# now, WITHOUT closing this session, open a NEW terminal and test:
$ ssh deploy@server # confirm key login works before you log out
fail2ban is a speed bump, not a strategy
Tools that ban IPs after failed logins (fail2ban) feel productive, but against keys-only SSH they are nearly pointless — there are no passwords to guess — and against a distributed botnet they are trivially evaded by rotating IPs. Keys-only authentication removes the threat entirely rather than slowing it down. Use fail2ban if you like to cut log noise, but never as a substitute for disabling password auth.