SSH Security Best Practices

SSH (Secure Shell) is the dominant remote administration protocol for Linux and Unix-based servers, and its configuration decisions directly determine the attack surface exposed on any networked system. This page covers the technical structure of SSH security, the classification distinctions between authentication methods, common misconfiguration scenarios, and the decision criteria that shape hardening priorities in enterprise and government environments. Regulatory frameworks from NIST, CIS, and CISA treat SSH hardening as a foundational server security control, not an optional enhancement.

Definition and scope

SSH is a cryptographic network protocol defined in RFC 4251 through RFC 4254, published by the IETF, that establishes encrypted tunnels for remote command execution, file transfer, and port forwarding. The security scope of SSH encompasses the daemon configuration, authentication mechanisms, cryptographic algorithm selection, key lifecycle management, and network-layer access controls governing who can initiate a session and under what conditions.

The Center for Internet Security (CIS) Benchmarks for Linux distributions dedicate discrete control sections to SSH daemon hardening, treating it separately from general user account policy. NIST SP 800-53, Revision 5, addresses remote access controls under control family AC-17, which directly governs SSH-based administrative access in federal systems (NIST SP 800-53 Rev. 5).

SSH operates on TCP port 22 by default — a port scanned continuously by automated adversarial infrastructure. The attack surface includes password brute-force, weak cryptographic algorithm negotiation, key theft, and misconfigured daemon options that permit privilege escalation or lateral movement. These are not theoretical vectors; the CISA Known Exploited Vulnerabilities Catalog includes SSH-related vulnerabilities from OpenSSH and vendor implementations.

For context on how SSH hardening fits within the broader server security service landscape, see the Server Security Providers reference.

How it works

SSH security is structured across four discrete layers, each representing a distinct point of control:

1. Transport layer — Establishes an encrypted channel using negotiated algorithms. The daemon and client exchange supported cipher suites, key exchange algorithms (KEX), and MAC algorithms. Weak or deprecated options — including arcfour, diffie-hellman-group1-sha1, and CBC-mode ciphers — must be explicitly disabled in /etc/ssh/sshd_config.

2. Authentication layer — Verifies the identity of the connecting party. SSH supports four authentication methods: public key, password, keyboard-interactive, and GSSAPI/Kerberos. Public key authentication using RSA (minimum 3072-bit) or Ed25519 keys is the standard hardened posture per NIST SP 800-57 Part 1, which governs cryptographic key management.

3. Connection layer — Multiplexes the encrypted session into logical channels for shell access, port forwarding, and SFTP subsystems. Restricting which subsystems and forwarding types are permitted reduces the attack surface without affecting primary administrative functions.

4. Access control layer — Operates through OS-level controls: AllowUsers, AllowGroups, DenyUsers, TCP Wrappers (/etc/hosts.allow and /etc/hosts.deny), and firewall rules restricting port 22 to named source IP ranges.

Public key vs. password authentication is the defining contrast in SSH hardening. Password authentication exposes the system to brute-force and credential stuffing attacks. Public key authentication requires possession of the private key file and, when combined with a passphrase, provides two-factor resistance. The CIS Benchmark for most Linux distributions assigns a scored recommendation to disable PasswordAuthentication in the SSH daemon. GSSAPI authentication is appropriate for Kerberos-integrated environments but should be disabled where that infrastructure is absent, as it adds attack surface without benefit in standalone deployments.

Common scenarios

Exposed administrative port on public interfaces — Default port 22 on a publicly routable interface receives automated login attempts within minutes of provisioning, as documented by the SANS Internet Storm Center's port trend reporting. Mitigation involves combining port restriction via firewall rules, AllowUsers directives, and disabling password authentication.

Overpermissioned SSH key deployment — A single SSH keypair authorized across 40 or more production servers creates systemic risk: compromise of one private key produces lateral access across the entire fleet. Key segmentation — unique keypairs per role or per host — limits blast radius. NIST SP 800-57 and NIST IR 7966 (Security of Interactive and Automated Access Management Using Secure Shell) both address SSH key lifecycle management.

Root login via SSH — Permitting direct root login (PermitRootLogin yes) bypasses the audit trail created by sudo and eliminates the break-glass visibility that separates user action from privileged action. CIS Benchmarks score PermitRootLogin to no as a required control.

Stale or unrevoked authorized keys — Authorized keys stored in ~/.ssh/authorized_keys do not expire automatically. Departing employees, decommissioned service accounts, or rotated keypairs that were never removed retain access indefinitely. This is a structural key management problem addressed in NIST IR 7966, which estimates that SSH keys in large organizations are often left unmanaged for years without formal inventory or revocation procedures.

The Server Security Provider Network Purpose and Scope page provides context for how professional SSH hardening services are categorized within the broader server security sector.

Decision boundaries

SSH hardening decisions involve tradeoffs between security posture and operational practicality. The following boundaries define where configuration choices shift from preference to requirement:

• Federal and FedRAMP environments — NIST SP 800-53 AC-17 and AC-2 mandate documented remote access policies, MFA for privileged access, and session logging. SSH without MFA integration (e.g., via FIDO2 hardware tokens or PIV cards) does not satisfy high-baseline FedRAMP controls.

• PCI DSS scope — Systems in the cardholder data environment must restrict interactive remote access by protocol and source. PCI DSS v4.0, published by the PCI Security Standards Council, requires that all non-console administrative access be encrypted and authenticated.

• Key-based vs. certificate-based SSH — At scale, managing individual authorized key files becomes operationally unsustainable. SSH certificates — signed by an internal Certificate Authority using OpenSSH's built-in CA functionality — provide expiring, revocable credentials without per-host key distribution. This transition is appropriate for fleets exceeding 20 managed hosts.

• Automated (non-interactive) SSH sessions — Service accounts using SSH for automated file transfer or job execution require careful key scoping. The command= option in authorized_keys restricts a key to a single permitted command, preventing interactive shell access regardless of how the key is used. NIST IR 7966 specifically addresses this scenario as a distinct risk category from interactive human access.

For a structured view of professional services operating in the SSH and server hardening sector, the Server Security Providers provider network provides categorized practitioner entries.