The SSH configuration that survives an audit is not the one with the longest file. It is the one where every directive is justified, documented, and applied from a single source instead of typed by hand once and forgotten.
Nearly every SSH compromise follows the same short path: a key whose owner left the company, root login still permitted on one host nobody remembered, or password authentication enabled on a box that was "temporarily" exposed two years ago. A checklist is how you close that path and prove that you did.
What the auditor actually asks
Nobody reads sshd_config line by line. They ask a handful of questions and check whether your answers are demonstrable rather than aspirational.
- Who can log in to this host, and can you produce that list from a single source of truth?
- Is key rotation enforced, or is it a sentence in a policy nobody tracks?
- Can one stolen key reach the whole fleet?
- Are authentication failures logged centrally, and does anyone review them?
- Is the configuration managed from code, or does every host drift on its own?
The baseline configuration
Authentication
Disable password and keyboard-interactive authentication outright. Set PermitRootLogin no and require named accounts with sudo. If root must be reachable in an emergency, use a console or a bastion, not an open door. Insist on modern key types — ed25519, or RSA at 4096 bits — and reject everything older.
Access scope
Put a bastion or jump host in front of production so no server accepts SSH from the public internet. Bind sshd to the management interface and use firewall rules as a second wall behind it. Use the AllowGroups directive to restrict which accounts each group can reach, so a single compromised user cannot pivot freely across the estate.
Session hygiene
Set short idle timeouts, disable port forwarding where it is not needed, cap concurrent unauthenticated connections, and turn off agent forwarding on shared hosts. These settings rarely break anything and remove entire classes of lateral movement.
Where compliance demands it, enable session recording on privileged hosts and store the transcripts alongside the audit trail. It sounds heavy until the first incident review, when a transcript saves a week of guessing about who ran what and when.
Keys are inventory, not credentials
Every key needs an owner, a creation date, and a rotation date. Tag the key comment with the person and the host, store revocations wherever grants are recorded, and remove access the day someone leaves rather than at the next quarterly review. Better still, move to short-lived certificates signed by a small internal certificate authority, so access expires by default instead of accumulating quietly for years.
Reachability is the other half of the problem. A key that still authenticates but is never used is a liability, so track last-used timestamps and retire anything dormant beyond a quarter.
Logging that proves the control works
Ship sshd logs to a central store the host itself cannot modify. Watch for failed authentication spikes, logins from unexpected regions, and successful logins by accounts that should never use SSH at all. A control nobody monitors is a control you cannot defend in a review.
Put a named owner on that queue each week. Unassigned logs are read by nobody, and the reviewer is what turns raw lines into a defensible control.
Hardening you cannot demonstrate is indistinguishable from hardening you never did.
How Weeltec applies this
Weeltec treats SSH access as configuration-managed state. Roles define who may reach which tier, keys and certificates are issued and revoked through automation, and each host is checked against the baseline on a fixed schedule, with drift raised as an incident rather than a footnote. By the time an audit arrives, the configuration history and revocation records already exist.
The rule
Turn off passwords. Scope access through a bastion. Inventory every key. Ship the logs somewhere the attacker cannot reach. Then re-run the check monthly and fix whatever drifted.
None of this is exotic, and none of it is expensive. All of it has to be enforced by something other than good intentions — configuration management, a schedule, and a person who owns the result.
Weeltec manages hardened, auditable server infrastructure for teams without a dedicated security function. If your SSH access model has never been reviewed, get a quote and we'll walk it with you.