SSH Hardening: The Definitive Configuration Guide

SSH hardening is not changing port 22. It is reducing who can authenticate, what a session can do, and how quickly the team can prove the service stayed available.

The common SSH checklist starts with a block of sshd_config and ends with a service restart. That skips the dangerous parts: inherited settings, cloud image drop ins, emergency access, key ownership, forwarding, workload impact, and effective configuration. A syntactically valid file can still lock out administrators or grant more capability than the author intended.

A sound SSH hardening process makes four decisions for every connection. Can the source reach the service? Is the identity approved? What can the session do? What evidence remains? Public key authentication answers part of the second question. It does not answer the other three.

What should SSH hardening accomplish?

SSH hardening should expose the daemon only where required, admit named identities through approved methods, prevent direct root access, restrict session features by job, protect host and user keys, resist connection abuse, log useful context, and preserve a tested recovery path. The configuration should be readable from the running daemon and reproducible across the fleet.

Remote administration belongs inside a larger host policy. Use the system hardening pillarfor ownership and baseline design. The Linux hardening checklist covers packages, services, firewall, kernel, recovery, and evidence around the daemon. Apple administrators should also read the macOS hardening guide before enabling Remote Login across a fleet.

How do you find the effective SSH configuration?

Record the OpenSSH version, package source, service unit, listener addresses, included files, host keys, allowed groups, authentication methods, network controls, and management owner. Then ask the daemon for effective state. Reading only /etc/ssh/sshd_config misses vendor and cloud image content.

The first trap is ordering. The official OpenBSDsshd_config manual says the first value obtained for a keyword is used unless the directive says otherwise. Included wildcard files are processed in lexical order. That means a file named99-hardening.conf does not reliably override an earlier value. In many layouts, it loses to it.

Inspect where the Include appears and which file sets each value first. A file named00-hardening.conf may be appropriate when the distribution includes that directory before its own defaults, but only sshd -T proves the result. This small rule is missing from many current guides, and it explains why a clean looking drop in can have no effect.

Which SSH authentication policy should you choose?

Disable direct root login. Allow a named administration group. Prove public key access for every required path, including automation and recovery, before turning password access off. Remove stale keys and require an owner, principal, issue source, last use, and expiry for each access grant.

Hardware backed keys or short lived SSH certificates reduce the cost of copied key files. Certificates work well at fleet scale because the server trusts a user certificate authority and principals instead of thousands of unmanaged public keys. Protect the signing path, keep lifetimes short, log certificate identity, and maintain a separate emergency method.

If policy requires more than one factor, configure and test the second method before enforcing it. OpenSSHAuthenticationMethods accepts ordered lists such as publickey,keyboard-interactive:pamwhen the platform and PAM stack support that design. Keep keyboard interaction enabled for this case. Disabling it while requiring it is an efficient way to lock out the entire team.

Verizon's 2026 Data Breach Investigations Report found a median 6 percent of users reused passwords and 4 percent used an already compromised password. Users were more than four times as likely to use a compromised password as a weak one. Stronger password rules do not fix reuse. SSH keys or certificates remove that password path from the daemon.

What does a practical OpenSSH server baseline look like?

The block below is a starting point for named administrators using public keys. Create and populate thessh-admins group first. Confirm the distribution supports every directive. If you need PAM based multifactor authentication, change the method deliberately rather than copying this block.

Upstream defaults are more permissive than many teams realize. The current manual listsMaxAuthTries 6, MaxSessions 10, MaxStartups 10:30:100, and password authentication enabled. A lower number is not automatically safer. Set limits against real automation, multiplexing, bastion, and recovery behavior, then load test the authentication path.

Do not add client keepalive values because a checklist says every session needs a timeout. A keepalive detects a dead client. It does not prove the user is idle. Current OpenSSH also supports channel timeouts, but they can close one channel while related processes remain. Define the behavior you need, test shells and transfers, and avoid treating a disconnected terminal as process cleanup.

How do you restrict what an SSH session can do?

Separate human administration, file transfer, backup, deployment, and port forwarding. A service identity should not receive an unrestricted shell because its job runs one command. Use authorized key options, certificate principals, Match blocks, ForceCommand, and operating system permissions to narrow the session.

Every directory component in a chroot path must meet OpenSSH ownership and write restrictions, so test the path with a representative account. The manual's DisableForwarding switch closes X11, agent, TCP, and local socket forwarding at once. It is useful for a forced command account. For an unrestricted shell, the manual warns that disabling a forwarding feature does not stop the user from installing another forwarder.

Agent forwarding deserves its own decision. It does not copy the private key to the server, but a privileged process on that server may use the forwarded agent while the connection exists. Prefer connections from a clean administration endpoint through a controlled access path. Do not forward a high privilege agent through hosts you do not fully trust.

Should SSH be exposed to the internet?

Usually, no. Put administration behind a private management network, identity aware access proxy, VPN, or bastion with a narrow source policy. If public reachability is required, restrict sources where possible, use keys or certificates, apply connection limits, watch authentication behavior, and keep the daemon current.

Changing the port cuts log noise from simple scans. It does not create a security boundary. An attacker can discover another port. Spend the effort on who can reach it, who can authenticate, what the account can do, and what evidence follows the session.

MITRE ATT&CK tracks SSH as Remote Services technique T1021.004, last modified May 12, 2026. Its procedure examples include groups using valid accounts, tunnels, brute force, and enabled SSH on ESXi. That is why successful login followed by process execution, privilege change, file transfer, or a new forwarding path deserves more attention than failed login volume alone.

Should you hard code SSH ciphers and algorithms?

Avoid copying a frozen algorithm list from a blog. OpenSSH defaults change, distributions backport fixes, and system crypto policy may control the final set. Start with a supported package and the vendor policy. Add an explicit restriction only for a named compliance or compatibility reason, and record the client population it affects.

The official OpenSSH release notes show how quickly the ground moves. OpenSSH 10.1 arrived October 6, 2025. Releases 10.2, 10.3, 10.4, and 10.5 followed by August 11, 2026. Version 10.5 included security fixes only five weeks after 10.4. A copied cipher block can preserve yesterday's assumptions while the maintained default keeps changing.

Inventory actual negotiation before removing an algorithm. Test automation, appliances, recovery consoles, old network devices, and external partners. Put a retirement date on any weak compatibility exception. The right fix is usually to update the client, not weaken every server.

How do you deploy SSH hardening without locking everyone out?

1. Verify console or another recovery path and name the person who can use it.
2. Keep the current session open. Start a second session through the exact path operators use.
3. Run sshd -t, then inspect sshd -T for the values that matter.
4. Test every required identity class, including automation, file transfer, break glass, and bastion access.
5. Reload the service using the distribution's unit name. Do not restart unless the platform requires it.
6. Open a fresh canary session, run a harmless command, test denied paths, and confirm logs arrived.
7. Deploy through rings, monitor failure and support volume, then expand.

Treat the file and result as two artifacts. Version the source configuration. Store the effective settings and test outcome with host identity, OpenSSH version, time, and change reference. The configuration drift detection guide explains how to keep the effective result from wandering after image or package change.

What should SSH logging and detection capture?

Capture source address, target host, user, accepted method, certificate or key fingerprint where available, session start and end, privilege elevation, file transfer, forwarding, configuration change, and service reload. Protect logs off the host and synchronize time. Alert when expected SSH sources disappear as well as when new ones appear.

Failed attempts are context, not a severity score. A successful login for a dormant administrator from a new source, followed by sudo and an outbound tunnel, matters more than ten thousand blocked guesses. Tie identity, endpoint, network, and process evidence into one case.

When should SSH keys become certificates?

Suppose 3,000 servers each trust five administrator keys. That is 15,000 trust entries. A quarterly review at two minutes per entry costs 500 hours, and copied files still do not expire themselves. The math is telling you the unit of management is wrong.

An SSH certificate authority can move the decision to a smaller set of trusted CAs, short certificate lifetimes, and named principals. It adds signing infrastructure and recovery work, so it is not free. At fleet scale, it replaces thousands of permanent file edits with a time bound identity decision.

Which SSH hardening advice should you ignore?

Ignore claims that another port stops attackers, a late numbered drop in overrides earlier values, disabling passwords is safe before keys are proven, or the longest cipher list is the strongest. Do not restart the daemon and close your old session at the same time. Do not give an automation identity a shell because restriction takes effort.

The blunt rule is simple: no configuration change is complete until a new approved session works, a prohibited session fails, the effective daemon state matches policy, and the log reaches its destination.

Frequently asked questions

Is disabling SSH password authentication enough?

No. It removes one attack path. You still need network restriction, approved identities, key lifecycle, root denial, session limits, capability controls, logging, patching, and recovery.

Should SSH run on a nonstandard port?

It can reduce simple scan noise, but it is not a material security boundary. Choose a port for operations, then secure reachability and authentication as if every attacker knows it.

Should PermitRootLogin always be set to no?

For human administration, yes. Use named accounts and controlled elevation. A narrow automated recovery or backup case may require a forced command design, but treat that as a tested exception with no unrestricted root shell.

How often should SSH configuration be reviewed?

Review effective state after package, image, identity, network, and policy changes, plus on a fixed cadence. Recheck keys and certificates when people or systems change roles. Track hosts that stop reporting.

The executive takeaway

Choose one SSH exposed role. Preserve console access, read the daemon's effective state, remove password and direct root paths only after key access works, restrict the session to its job, and prove both an allowed and denied connection. Deep endpoint context with AI driven analysis can connect SSH state with identities, processes, and exposure, but a reliable access design still needs an owner. Hardening ends with a tested boundary, not a reload.