Hardening SSH: Keys, users and firewall rules that make sense

Test a second connection before tightening access

The most common SSH hardening failure is not a weak rule but locking yourself out. Open a second session and fully test the new key before disabling password or root login. Keep the existing session open until both the SSH configuration and firewall have been verified.

Personal accounts instead of shared root access

Create an individual account for each administrator and grant sudo only where needed. This keeps actions attributable in logs and allows access to be removed per person. Private keys stay on the user's device; only the public key belongs in the server's authorized_keys file.

Settings worth reviewing

• Test public-key login: only then disable password authentication.
• Avoid direct root login: sign in with a personal account and use sudo.
• Disable unused features: allow agent, TCP or X11 forwarding only when required.
• Validate before reload: check syntax and keep the current session open.

Firewall and rate limits add another layer

Where your workflow allows it, permit SSH only on the required interface or from known source networks. Moving to another port mostly reduces log noise and does not replace strong authentication. Automated bans can slow repeated login attempts, but need sensible settings to avoid blocking legitimate users.

Security continues after setup

Apply security updates, remove stale keys and review failed login attempts. Document how to regain access through a console or rescue environment after losing a key. Good hardening is a small, repeatable routine rather than a one-time switch.

Explore additional platform and network protection under features and DDoS protection.