SSH audit and key management still expose NHI governance gaps

At a glance

What this is: This is a security analysis of SSH access management that shows why passwords, shared keys, and unmanaged keys weaken auditability and revocation.

Why it matters: It matters because SSH keys are non-human identities in practice, and weak lifecycle control over them creates the same governance failures IAM teams already battle in service accounts, tokens, and other privileged machine access.

👉 Read StrongDM's analysis of SSH key management and auditability

Context

SSH is a remote access protocol for Linux and BSD environments, but the governance problem starts when each key becomes an unmanaged credential tied to a real permission boundary. Once access is distributed across many users and servers, the hard part is no longer login itself. It is knowing who has which key, where it is installed, and how quickly it can be revoked.

For IAM and security teams, SSH is a familiar example of NHI sprawl: credentials are provisioned ahead of use, shared too easily, and often outlive the people or systems they were meant to support. That makes SSH a lifecycle and audit problem as much as an authentication problem, and the controls needed here map directly to broader NHI governance.

The same pattern shows up in service accounts, API keys, and other machine credentials. The starting point is typical for teams that grew access organically: manual key distribution, uneven rotation, and limited session visibility.

Key questions

Q: How should security teams manage SSH keys across many servers?

A: They should treat SSH keys as governed credentials with named ownership, explicit host bindings, and defined rotation and revocation rules. The key control is not just generation, but lifecycle management across every server where the credential is trusted. That prevents silent key sprawl and makes access removal operationally possible.

Q: Why do shared SSH keys create governance risk?

A: Shared keys break attribution, weaken offboarding, and make it impossible to know which person actually initiated a session. They also hide whether a key has been copied to unauthorized devices. In practice, shared SSH credentials turn a manageable identity into an untraceable access path.

Q: What breaks when SSH access is not centrally audited?

A: Without centralized auditing, teams lose consistent session records, cannot reconstruct destructive actions easily, and struggle to prove which user performed which command. That weakens compliance, slows incident response, and leaves key revocation disconnected from real usage patterns.

Q: Who should be accountable for SSH access when employees leave or change roles?

A: Accountability should sit with the identity and access process, not just system administrators. SSH access must be removed through offboarding and role-change workflows, with keys revoked wherever they were provisioned. If that process is manual, stale access will outlive the business need.

Technical breakdown

Why SSH keys become a lifecycle problem

SSH public-key authentication shifts trust from a password the user knows to a private key they possess. That improves security, but only if the private key remains controlled, unique to one identity, and revocable on demand. Once keys are shared, copied to multiple devices, or left on many hosts, they become a lifecycle problem rather than just an authentication mechanism. The operational challenge is not generation. It is maintaining ownership, rotation, and removal across the full access path.

Practical implication: treat SSH keys as governed NHI credentials with assignment, rotation, and revocation tracked to a named owner.

How bastion hosts reduce, but do not remove, SSH risk

A bastion host collapses many user-to-server connections into one controlled entry point. That improves visibility and makes revocation easier because administrators have fewer places to remove access. But it does not solve session-level accountability on its own, and it can become another concentration point for privileged access if key sprawl continues behind it. In practice, the bastion pattern reduces distribution complexity while preserving the underlying problem of who can access what and under which conditions.

Practical implication: use bastions to centralise entry, but still enforce per-user authorization and session logging at the gateway.

Why centralized proxy access changes auditability

A proxy-based access layer changes the control point from individual servers to a central gateway. That allows teams to issue temporary credentials, enforce role-based access control once, and record session activity consistently across destinations. The important technical shift is that identity policy is no longer duplicated across every target host. Instead, the gateway becomes the authoritative place for authentication, authorization, and audit trails, which reduces drift and improves incident reconstruction.

Practical implication: concentrate SSH policy enforcement at one control layer so access logs, session evidence, and revocation actions stay consistent.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SSH key sprawl is a classic NHI governance failure, not just an administration inconvenience. The article shows how quickly per-user keys become ungovernable once teams scale beyond a handful of servers. Rotation becomes inconsistent, revocation becomes slow, and attribution breaks when credentials are shared or copied. The field-level lesson is straightforward: unmanaged SSH keys behave like any other non-human identity without lifecycle control, and that is where control collapses.

Centralizing SSH access reduces distribution risk, but only if the access boundary is still identity-aware. Bastion hosts lower the number of places where keys must be managed, yet they can also concentrate privilege and obscure what happens after login. That means the governance question is not whether to centralize, but whether the central point preserves per-user accountability, session evidence, and command-level traceability. Practitioners should evaluate access proxies as governance layers, not just transport relays.

Auditability is the real dividing line between acceptable SSH and unmanaged privilege. The article correctly treats logging as a core control because identity without traceability cannot support compliance, forensics, or least-privilege enforcement. In NHI terms, SSH access becomes governable only when every credential is tied to a lifecycle owner and every session is reconstructable. That is the difference between access and accountability.

SSHD configuration hardening still leaves the underlying NHI lifecycle problem intact. Disabling password logins and root access reduces obvious exposure, but it does not answer who owns the keys, how often they change, or how quickly they are removed when roles change. That is why SSH security cannot be solved as a server-hardening exercise alone. It needs identity governance across the credential lifecycle.

Ephemeral access for SSH is the right direction because standing privilege is the wrong assumption. Standing SSH authorization was designed for a world where access persists long enough to be manually reviewed. That assumption fails when teams distribute keys across users and hosts faster than they can track them. The implication is not just better controls, but a governance model that stops treating SSH credentials as durable entitlements.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which shows that governance gaps often persist after policy is written.
• That same control gap is why readers should also review NHI Lifecycle Management Guide for credential ownership, rotation, and offboarding patterns.

What this signals

SSH is an NHI governance problem when keys outlive the people and systems they were issued to. Teams that still manage keys manually should expect the same failure mode they see with leaked secrets: long remediation windows, weak ownership, and incomplete revocation. The practical signal is to move SSH into the same lifecycle discipline used for other privileged machine credentials, with inventory, ownership, and removal tied to change events.

Centralized access layers should be measured by accountability, not convenience. If a proxy or bastion improves operations but cannot prove who did what during a session, it has reduced complexity without solving governance. That is why SSH programs should be aligned with the NIST Cybersecurity Framework 2.0 functions for protect, detect, and respond, not just access provision.

For practitioners

• Inventory every SSH credential and host binding Build a complete register of which users own which SSH keys, where each key is installed, and which servers still trust it. Without that inventory, revocation and rotation remain partial and audit evidence stays fragmented.
• Remove shared SSH credentials from production workflows Eliminate shared logins and require unique credentials per user so session activity can be attributed cleanly. Shared keys make it impossible to prove who connected, who approved access, and who should be offboarded when roles change.
• Centralize SSH access through a governed proxy layer Use a single access control point to issue temporary credentials, enforce role-based access control, and capture session logs before traffic reaches target systems. This reduces host-by-host drift and makes revocation operationally realistic.
• Tie key revocation to offboarding and role change events Connect access removal to joiner-mover-leaver workflows so keys are removed when people leave or change responsibilities. If revocation depends on manual cleanup, expired access will persist across servers longer than anyone expects.

Key takeaways

• SSH becomes a governance risk when keys are shared, copied, and left behind after roles change.
• The evidence in the article points to key proliferation, weak revocation, and limited auditability as the main control failures.
• Teams need centralized accountability for SSH credentials, not just stronger server hardening.

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 controlled server that acts as a single entry point into a private environment. It reduces the number of places where credentials must be distributed and monitored, but it does not by itself solve session visibility or identity accountability after login.
• Auditability: The ability to reconstruct who accessed a system, when they accessed it, and what they did. For SSH, auditability depends on central logging, stable identity attribution, and enough session detail to support compliance and incident investigation.
• Standing privilege: Access that remains valid until someone manually removes it. For SSH and other non-human credentials, standing privilege becomes a control weakness when access outlives the business need, the owner, or the system it was issued for.

Deepen your knowledge

SSH key governance and lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building access governance for server credentials, it is worth exploring.

This post draws on content published by StrongDM: SSH Audit Made Simple. Read the original.