Notifications
Clear all
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.
NHIMG editorial — based on content published by StrongDM: SSH Audit Made Simple
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Remove shared SSH credentials from production workflows Eliminate shared logins and require unique credentials per user so session activity can be attributed cleanly.
- 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.
What's in the full article
StrongDM's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step SSH server hardening settings for password login, root login, and key-based authentication.
- Operational trade-offs between individual key management, bastion hosts, and proxy-based access control.
- How centralized audit trails support compliance, attribution, and session reconstruction during investigations.
👉 Read StrongDM's analysis of SSH key management and auditability →
SSH audit and key management: what IAM teams still miss?
Explore further
08/06/2026 6:54 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: SSH audit and key management still expose NHI governance gaps
