OpenSSH Hardening in the OpenSSH 10 Era: A Practical VPS Policy Baseline

OpenSSH Hardening in the OpenSSH 10 Era: A Practical VPS Policy Baseline

SSH remains the control plane for most VPS operations. If SSH policy is weak, everything else is eventually at risk.

OpenSSH has continued to evolve, but many servers still run outdated access patterns from years ago. This guide gives you a practical baseline that balances security and operational recovery.

Security objective

Your SSH layer should provide:

• strong authentication
• narrow exposure
• auditable access
• low lockout risk during changes

Many teams get three of four and ignore lockout risk, then learn the hard way.

Baseline policy profile

Use this as a starting profile:

1. Disable password authentication for standard operations.
2. Disable direct root login.
3. Restrict users and source ranges where possible.
4. Enforce modern key algorithms and key lengths.
5. Log and monitor authentication anomalies.

Policy baseline should be defined once and reused across hosts.

A concrete sshd_config baseline (adapt to your environment)

This is intentionally conservative. Apply via canary and verify remote access before broad rollout:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
AuthenticationMethods publickey

MaxAuthTries 3
LoginGraceTime 30

If you rely on PAM-based 2FA, adjust KbdInteractiveAuthentication and AuthenticationMethods accordingly.

Configuration strategy: change safely

Never harden SSH by editing production config live without a recovery path.

Safe rollout pattern:

1. Open a second active SSH session.
2. Apply config change on one host or canary environment.
3. Validate new login path from a separate client.
4. Reload SSH service.
5. Close old session only after successful verification.

This avoids accidental fleet-wide lockouts.

Network controls matter as much as sshd_config

SSH security is stronger when network policy helps:

• allow access only from known operator IP ranges
• move high-risk administrative hosts behind VPN or bastion
• rate-limit repeated failed attempts

Application-layer hardening without network boundaries is incomplete.

Key lifecycle discipline

Key management failures are a common weak point. Use process rules:

• unique key per operator and device
• mandatory key rotation cadence
• immediate revocation on role or device change
• no shared private keys in team chat, docs, or ticket tools

If one compromise cannot be isolated quickly, your model is too loose.

Auditability and accountability

At minimum, you should know:

• who logged in
• from where
• when
• what privileged actions happened

Tie SSH identity to human ownership, not generic “devops” accounts.

Break-glass access without chaos

You still need emergency recovery controls:

• documented break-glass path
• restricted and audited emergency credentials
• time-boxed access and immediate review after use

Strong security that blocks incident recovery is not strong security.

Example policy review cadence

Use a monthly mini-audit:

• check for stale authorized keys
• verify password auth is still disabled where expected
• review failed login trends
• test recovery procedure in staging

Short, recurring reviews outperform annual security theater.

Final recommendation

Treat SSH hardening as a living policy program, not a one-time config tweak. In practice, teams that maintain key hygiene, network boundaries, and safe rollout procedures have dramatically fewer access incidents.

Reference

• sshd_config(5) manual (authoritative option behavior): man.openbsd.org
• sshd(8) manual (testing and daemon behavior): man.openbsd.org