SSH audit and key management still expose NHI governance gaps

At a glance

What this is: This is a StrongDM analysis of SSH access governance, arguing that key-based login improves security over passwords but still leaves audit, revocation, and scale problems unresolved.

Why it matters: It matters because SSH is still a common administrative path, and IAM and PAM teams need to govern keys, permissions, and traceability across NHI lifecycles rather than treating SSH as a purely technical protocol.

Context

SSH is a remote access protocol for Unix-like systems, but in identity terms it functions as a non-human access path that often outlives the governance applied to it. The article shows that once teams move beyond a single user and a single server, key ownership, rotation, revocation, and attribution become the real control problem.

The security gap is not limited to authentication strength. Shared logins, inconsistent key generation, and manual server provisioning all create conditions where access exists without clear accountability, which is exactly where NHI governance starts to fail in practice.

Key questions

Q: What breaks when SSH keys are managed manually across many systems?

A: Manual management breaks inventory accuracy, ownership clarity, and timely revocation. Keys get copied, forgotten, and left behind on servers that no one actively reviews. The result is access sprawl, especially in environments with contractors, automation, or many ephemeral servers. Visibility and central control are the first things that fail.

Q: Why do SSH keys need stronger governance than passwords?

A: SSH keys are easier to use at scale, but they create a longer-lived credential estate that must be owned, rotated, and revoked. Without lifecycle control, keys outlive the access need they were created for, and that persistence increases the chance of unauthorised reuse or orphaned access.

Q: How can teams tell whether SSH audit logging is actually useful?

A: Audit logging is useful when each session can be tied to one identity, one target host, and one action trail. If logs cannot distinguish shared access, unmanaged keys, or proxy-bypassed sessions, the organisation has telemetry but not auditability.

Q: What is the difference between a bastion host and central SSH governance?

A: A bastion host is an access choke point, while central SSH governance is the policy and control model behind that choke point. A bastion can reduce sprawl, but without role-based access, key ownership, and revocation processes it only relocates the governance problem.

Technical breakdown

Why SSH key pairs create governance debt

SSH key-based login shifts trust from a memorised secret to a private key stored on a device, which is usually stronger than password-only access. But the control surface expands immediately: each key needs ownership, protection, rotation, and revocation, and those responsibilities become harder to prove as the estate grows. The article also notes that private keys may be passphrase-protected or loaded through ssh-agent, but that does not remove the need to know where keys live and who can use them. In NHI terms, SSH keys are credentials with a lifecycle, not just a login mechanism.

Practical implication: Treat SSH keys as governed non-human credentials and map them to an owner, rotation rule, and revocation path.

Why auditability breaks down across shared and manual access paths

SSH auditability depends on being able to link a session to a specific person or process and then retain enough context to reconstruct what happened. The article points out that shared credentials, overlapping server access, and manually provisioned keys make that attribution unreliable. Bastion hosts improve visibility by collapsing many-to-many access into a narrower choke point, but they still do not fully solve session-level accountability or content inspection. For IAM and PAM teams, this is the difference between knowing that a server was reached and knowing who actually performed the action.

Practical implication: Centralise session logging and require per-user attribution before relying on SSH logs for investigation or compliance.

How bastion hosts and proxy layers change the control model

A bastion host reduces the number of places where access keys must be managed, but it also becomes a central trust anchor. That simplifies revocation and monitoring, yet it reintroduces scale pressure once teams add multiple network segments, multiple bastions, or host-specific rules. The StrongDM model described in the article is still proxy-based, but it pushes authentication, authorisation, temporary credentialing, and logging into one control point rather than distributing them across every destination server. The architectural lesson is that SSH governance improves when the access plane is separated from the workload plane.

Practical implication: Use a central access layer to enforce temporary credentials, role-based controls, and unified audit logging across SSH destinations.

NHI Mgmt Group analysis

SSH key sprawl is an NHI lifecycle problem, not just an authentication problem. The article makes clear that keys proliferate once teams move beyond one user and one server, and that ownership, rotation, and revocation become difficult to govern consistently. That is the real failure mode: credentials remain valid long after the operational relationship that justified them has changed. Practitioners should treat SSH keys as governed NHIs with explicit lifecycle control.

Shared SSH access breaks attribution before it breaks access. If multiple people use the same login path or the same key material, session records may show activity but not accountable identity. That weakens incident review, privileged access oversight, and compliance evidence at the same time. The operational implication is that auditability must be designed into the access model, not inferred from server logs after the fact.

Centralising SSH through a proxy or bastion helps, but it does not remove governance responsibility. A choke point improves monitoring and revocation, yet it also becomes the place where trust, logging, and authorisation concentrate. That makes the access layer more governable, not automatically governed. Teams should evaluate whether their SSH architecture creates a single point of control or merely a single point of failure.

Fine-grained SSH control should be aligned to PAM and NHI governance together. The article shows that root login suppression, sudo scoping, and key distribution all sit in the same decision chain. Separating those controls across different teams often leaves gaps between access approval, server provisioning, and audit retention. Practitioners need one operating model for privilege, not a collection of disconnected SSH settings.

Auditability becomes the decisive control once scale increases. At small scale, manual key provisioning can appear manageable, but the article is explicit that complexity grows quickly with users and servers. When that happens, the issue is no longer convenience. It is whether the organisation can still prove who had access, what was done, and when it should have been removed.

What this signals

SSH key governance now sits inside the broader NHI control problem. Once private keys, audit trails, and revocation are spread across many servers, the organisation is managing a non-human credential lifecycle whether it calls it that or not. The practical signal is that SSH should be folded into the same inventory, ownership, and offboarding discipline used for other machine identities.

Auditability is the control that separates manageable SSH from unmanaged SSH. If teams cannot connect a session to a person and preserve the action trail, they have a logging problem and a governance problem at the same time. The next step is to decide whether SSH belongs under a distributed server model or a centralised access layer with explicit control ownership.

For practitioners

• Map every SSH key to a named owner Create an inventory that ties each public key to one accountable person or service, then remove shared key use from privileged server access paths.
• Enforce key rotation and revocation rules Set a rotation cadence for SSH keys, revoke keys when employees leave or roles change, and verify that stale keys are removed from authorized_keys files.
• Centralise audit logging for SSH sessions Route SSH access through a controlled access layer that records who connected, what host was reached, and what commands were executed.
• Eliminate direct root logins Disable password-based and root-based SSH access, then use sudo or command-scoped access so elevated actions remain attributable to a specific user.

Key takeaways

• SSH is still widely used for server access, but its key management model creates an NHI governance burden once estates become large or shared.
• The article shows that the main failure points are attribution, revocation, and rotation, not encryption strength alone.
• Teams that centralise access control and session logging can make SSH auditable without relying on manual server-by-server key administration.

Key terms

• SSH key lifecycle: The full governance path for an SSH key from creation to revocation. It includes ownership, deployment, rotation, backup handling, and removal from every host that trusts it. In practice, lifecycle control is what makes SSH credentials auditable rather than merely functional.
• Bastion Host: A bastion host is an intermediary system used to reach protected internal resources. It centralises entry but also concentrates trust and availability risk, which means the design only works well when logging, offboarding, and recovery are tightly controlled.
• Auditability: Auditability is the ability to reconstruct who or what acted, what permissions were used, and what data or tools were touched. For AI and NHI governance, it is the minimum evidence needed to investigate incidents, validate controls, and prove that autonomous actions stayed within approved scope.
• Authorized_keys: The authorized_keys file is the server-side list of public keys allowed to authenticate to a user account. It is a governance boundary as much as a technical file, because stale entries extend access and undermine offboarding, rotation, and least privilege.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or PAM programme, it is worth exploring.