Linux SSH hardening: reduce remote-login risk without locking yourself out

Create a recoverable administrator path first

Before disabling anything, prove a named administrative account can authenticate with its intended SSH key and elevate privileges. Keep the current session open while testing a second session so a typo does not become a lockout.

Know the provider-console or recovery route before changing SSH access on a remote-only server.

Prefer keys and minimize direct privileged login

Public-key authentication avoids sending a reusable password to the server and supports per-person credentials. Disable direct root login when the operating model supports a named account plus controlled privilege escalation.

Removing password authentication is useful only after every legitimate automation and operator has a working key path.

Limit exposure without confusing obscurity for security

A host firewall or upstream firewall can restrict SSH to expected source networks where practical. Changing the port may reduce noise but does not replace authentication, updates, logging, or rate controls.

Review authorized_keys and remove credentials that no longer have an owner.

Validate syntax and preserve auditability

Run sshd configuration validation before reload, then test new connections and sudo behavior. Monitor authentication logs and automate security updates according to the server’s maintenance policy.

• Prove a second login before closing the first.
• Use per-person SSH keys.
• Keep a recovery-console path.
• Validate sshd configuration before reload.