Topic starter
08/06/2026 4:59 pm
TL;DR: SSH remains the default remote access path for Linux and BSD systems, but passwords, shared keys, weak rotation, and limited auditability still create gaps that complicate attribution and revocation, according to StrongDM. The governance problem is not SSH itself, but the way key sprawl turns basic access into an unmanaged NHI lifecycle.
Editorial analysis by NHI Mgmt Group, based on content published by StrongDM: “SSH Audit Made Simple”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: SSH is still widely used for server access, but its key management model creates an NHI governance burden once estates become large or shared.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/06/2026 6:54 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: SSH audit and key management still expose NHI governance gaps
This post was modified 4 days ago by NHI Mgmt Group