SSH hardening on a Linux server — a practical checklist

For operators with one or a few internet-facing Linux hosts who want fewer opportunistic attacks without a full redesign of the estate.

Key takeaway

Most real-world SSH abuse is opportunistic: password guessing and open root login. Disabling password auth, blocking direct root, restricting who can connect, and verifying with sshd -T removes the easy wins — if you keep a recovery path open while you change config.

Why defaults are not enough

OpenSSH is built for compatibility. On a public VPS that often means password auth still possible, root reachable over the network, and port 22 open to the world. Attackers do not need a clever exploit; they need a weak login path.

This guide is a practical checklist for a single Linux server, not a CIS audit of a whole fleet.

Before you change anything

1. Keep an existing SSH session open until a new login works.
2. Prefer console or provider recovery access (Hetzner, DigitalOcean, AWS, etc.) before you disable passwords.
3. Prefer a second admin user with a working key before you turn off password auth.
4. Take a note of the current effective config: sudo sshd -T | less.

Checklist

1. Prefer key authentication; disable passwords

In /etc/ssh/sshd_config (or a drop-in under /etc/ssh/sshd_config.d/):

• PasswordAuthentication no
• KbdInteractiveAuthentication no (where supported)
• Confirm your user can log in with a key first

2. Disable direct root login

• PermitRootLogin no
• Use a normal user + sudo instead

3. Limit who can connect

• AllowUsers youradmin (or AllowGroups ssh-users)
• Keep the list short; update it when staff change

4. Tighten session behaviour

Useful starting points (tune to your needs):

• MaxAuthTries 3
• LoginGraceTime 30
• ClientAliveInterval 300 and ClientAliveCountMax 2 for idle disconnects

5. Restrict network exposure

Hardening sshd is weaker if the whole internet can reach it forever.

• Firewall: allow SSH only from trusted IPs or a VPN where practical
• Changing the port reduces noisy scans; it is not a substitute for keys and access limits

6. Validate, then reload

sudo sshd -t
sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin|allowusers'
sudo systemctl reload ssh   # or sshd, depending on distro

Test a new login in a second terminal before you close the safety session.

What this does not replace

• Patching and unused services still matter
• Docker-published ports can bypass host firewall assumptions — that is a separate problem
• A checklist is not a full server hardening project (accounts, firewall policy, proxy exposure, backups)

Practical next step

If you want the changes applied and verified on one Linux server — with a change record and recovery notes — that is the shape of a Linux server hardening engagement (from £650). Prefer a short conversation first: book a free 15-minute intro call via contact or view the server hardening service.

Available in Derby, Burton-on-Trent and across the UK.