Most organisations cannot say how many SSH keys grant access to their servers, who holds the private halves, or which of those keys belong to automation that nobody owns any more. NIST IR 7966 found that SSH key-based access had been largely ignored, and unmanaged authorized keys can bypass privileged access management for years. Tools that address this fall into three groups: discovery and governance of existing keys, SSH certificate authorities that replace static keys with short-lived certificates, and privileged access brokers that hold or issue credentials per session. This vendor-neutral buyer's guide helps infrastructure, PAM and identity teams define requirements, compare approaches and run a proof of concept. Operational practices are covered in the SSH Key Management Guide; this page is about choosing a product.
Key takeaways
- Discovery comes first. No tool can govern keys it cannot find, so test discovery of authorized keys, private keys and trust relationships on your own servers before anything else.
- Certificates beat static keys for people. Short-lived SSH user certificates signed by a CA, with principals and validity limits, remove most of the authorized_keys sprawl for interactive access.
- Automation keys need different controls. Machine-to-machine keys need command and source restrictions, owners and rotation without breaking jobs.
- Lock down where keys can live. Moving authorized keys to root-owned locations stops users and attackers adding their own.
- The CA or vault becomes tier 0. Whoever controls the signing key or the key vault controls access to every server, so evaluate its protection as hard as the features.
Define requirements
- Estate: Number of Linux and Unix hosts, network devices and appliances that accept SSH; cloud instances that live minutes or hours; Git hosting that uses SSH keys and deploy keys.
- Access types: Interactive administrator access, break-glass access, file transfer (SFTP and SCP), configuration management and CI/CD pipelines, and application-to-application trust.
- Current state: Whether keys are in user-owned ~/.ssh/authorized_keys files, whether a CA or bastion is already in place, and how keys are issued and removed today. See How to find SSH authorized keys across a server fleet.
- Identity source: Which identity provider or directory will decide who may obtain a certificate or session, and how group membership maps to Unix accounts.
- OpenSSH versions: Oldest OpenSSH and non-OpenSSH implementations in scope, since certificate and FIDO key support depend on them.
- Audit needs: Session recording, command logging and evidence of who used which key, when and from where.
Approaches compared
| Approach | How it works | Best fit | Trade-offs to test |
|---|---|---|---|
| Key discovery and governance | Agent or agentless scanning of hosts for authorized keys, identity keys and configurations; maps trust relationships; manages rotation and removal | Large legacy estates with years of static keys and automation trust | Scanning credentials and their privilege, coverage of non-standard paths, safe rotation of automation keys |
| SSH certificate authority | Users and hosts get certificates signed by a CA; servers trust the CA via TrustedUserCAKeys; certificates carry principals, validity and options | Interactive human access, ephemeral cloud hosts, host key verification at scale | CA key protection, issuance tied to SSO and MFA, revocation via key revocation lists, legacy implementations without certificate support. See the SSH Protocol and Certificate Authority Guide. |
| Privileged access broker or bastion | Users connect through a proxy that injects a vaulted key or issues a session credential, with recording | Regulated environments needing session recording and approval workflows | Single point of failure, latency, bypass if direct SSH stays open. See the PAM Buyer's Guide. |
| Centralised key lookup | sshd fetches keys or principals from a central service through AuthorizedKeysCommand or AuthorizedPrincipalsCommand | Organisations with a strong directory that want central control without a full CA | Availability of the lookup service, behaviour when it is unreachable, hardening of the command |
Most mature programmes combine them: certificates for people, governed and restricted keys or workload identity for automation, a broker for the most sensitive systems, and discovery running continuously to catch anything that slips back in.
Capability areas
| Area | What to look for |
|---|---|
| Discovery | Finds authorized keys in every configured AuthorizedKeysFile path, private identity keys, keys for root and service accounts, orphan authorized keys with no known private key, and server configuration such as PermitRootLogin and accepted algorithms |
| Trust relationship mapping | Which key on which host can reach which account on which other host, including chains across environments such as development to production |
| Usage analysis | Uses sshd fingerprint logs to show which keys were used and when, so unused keys can be proposed for removal |
| Lock-down | Moves authorized keys to root-owned locations through AuthorizedKeysFile or AuthorizedKeysCommand, so users cannot add keys themselves |
| Certificate issuance | Issues user certificates with identity (-I), principals (-n), short validity (-V) and options such as source-address, force-command and no-port-forwarding; issues host certificates (-h) |
| Revocation | Generates and distributes key revocation lists through RevokedKeys, with atomic replacement on every host |
| Hardware-backed keys | Supports ecdsa-sk and ed25519-sk FIDO keys, with touch and verify-required policies for administrators |
| Automation keys | Owner assignment, command and source restrictions, staged rotation that updates both ends, and alternatives such as workload identity |
| Workflow and approval | Requests approved by someone other than the requester, time-limited access, integration with ticketing |
| Logging and reporting | Every issuance, rotation and removal logged with actor; SIEM export; policy compliance reports |
Evaluation criteria
The weights are an NHI Mgmt Group suggestion for an estate of several thousand Linux servers with legacy automation, not a sourced benchmark.
| Criterion | Suggested weight | Evidence to request |
|---|---|---|
| Discovery completeness on your hosts | 20% | Pilot scan results compared with a manual sample |
| Safe remediation of automation keys | 20% | Live rotation of a key used by a scheduled job without failure |
| Certificate or brokered access for people | 15% | SSO and MFA-gated certificate issuance with short validity |
| Protection of the CA key or vault | 15% | HSM or KMS details, admin model, quorum for CA operations |
| Coverage of legacy and non-OpenSSH systems | 10% | Tested list of platforms, appliances and versions |
| Logging, reporting and SIEM integration | 10% | Sample events and compliance reports |
| Availability and break-glass | 10% | Behaviour when the CA, broker or lookup service is down |
Where identity fits
SSH keys are non-human identities in two ways: the keys used by automation are credentials for services, and even keys belonging to people outlive the person when nobody removes them. NIST IR 7966 lists unknown access, backdoor keys, stolen or unterminated keys, and lateral movement through chained trust as the main risks. Attackers add their own key to authorized_keys for persistence (ATT&CK T1098.004), steal private keys from disks (T1552.004) and move laterally over SSH (T1021.004). The Cursor marketplace extension compromise planted an attacker SSH key, which is exactly what lock-down and continuous discovery are meant to catch. Host keys matter too: the GitHub RSA SSH host key exposure forced a global rotation, and host certificates make that kind of change easier to roll out. See the SSH Key Compromise Response Playbook.
Questions to ask vendors
- Show us discovery on our hosts, including authorized keys outside ~/.ssh, keys for root, and orphan authorized keys with no matching private key.
- What credentials does your scanner or agent need, how are they protected, and what can an attacker do with them if your platform is compromised?
- How do you rotate a key used by an unattended job on both the client and the server without an outage, and how do you roll back?
- Where is the SSH CA signing key held, who can use it, and is a quorum required to change CA configuration?
- What is the default certificate validity, and can certificates be bound to source addresses and to the user's SSO session and MFA?
- How do you revoke a certificate or key across every host, and how quickly does the key revocation list reach them?
- What happens to access if your CA, broker or lookup service is unavailable, and what is the break-glass path?
- Which platforms are supported: OpenSSH versions, network devices, appliances, Windows OpenSSH and mainframes?
- Can you enforce command and source restrictions on automation keys, and report keys without them?
Red flags
- Discovery limited to keys the product itself issued.
- A CA signing key stored in software on a general-purpose server, or certificates issued with no expiry (ssh-keygen's default validity is unlimited unless -V is set).
- Rotation that only replaces the private key and leaves the old public key authorised.
- A broker that can be bypassed because direct SSH and user-writable authorized_keys files remain.
- Scanning that requires a standing root password or key on every host with no vaulting.
- No answer for automation keys, only for human administrators.
Proof of concept
- Pick a representative slice: 50 to 100 hosts across development and production, including a legacy distribution, a network device and a host used by scheduled jobs.
- Run discovery in report-only mode and compare with a manual sample; check that cross-environment trust relationships are shown.
- Analyse usage from sshd logs over the pilot period and list keys with no recorded use. NIST IR 7966 suggests a review window of about 6 to 12 months for removal decisions, so treat pilot results as candidates only.
- Lock down a test ring: move authorized keys to a root-owned location and confirm users can no longer add keys.
- Issue certificates to a pilot group through SSO and MFA with a validity of hours, and configure TrustedUserCAKeys and AuthorizedPrincipalsFile on the ring.
- Rotate one automation key used by a real job with command and source restrictions applied, and confirm the job still runs.
- Revoke and verify: revoke a certificate and a key, distribute the key revocation list and confirm both are refused.
- Test failure: take the CA or broker offline and exercise the break-glass procedure, then roll the ring back to its original configuration to prove rollback works.
Measuring success after go-live
- Number of authorized keys in user-writable locations, trending to zero.
- Percentage of interactive SSH logins using certificates or brokered sessions.
- Automation keys with an owner, command restriction and source restriction.
- Keys with no recorded use in the review window, and time to remove them.
- Median certificate validity for human users.
Framework mapping
| Framework | Reference | How SSH key management supports it |
|---|---|---|
| NIST IR 7966 | Sections 5.1 to 5.5 | Provisioning, termination, monitoring, inventory and remediation of SSH user keys |
| NIST SP 800-53 Rev. 5 | IA-5, IA-5(2), AC-2, AC-17, AU-2 | Authenticator management, public key-based authentication, account management, remote access, event logging |
| NIST CSF 2.0 | PR.AA-01, PR.AA-03 | Credentials for users and services managed and authenticated |
| CIS Controls v8.1 | Control 5 (Account Management), Control 6 (Access Control Management) | Inventory and removal of credentials, centralised access control |
| MITRE ATT&CK | T1098.004, T1552.004, T1021.004 | Persistence through authorized keys, private key theft, lateral movement over SSH |
Standards and references
- NIST: IR 7966 Security of Interactive and Automated Access Management Using Secure Shell (SSH)
- OpenBSD: sshd_config manual page
- OpenBSD: ssh-keygen manual page
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: SP 800-57 Part 1 Rev. 5 Recommendation for Key Management
- NIST: Cybersecurity Framework 2.0
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support for SSH key, PAM and non-human identity programmes. Browse vendors in our NHI and AI products directory or contact us.
Related NHI Mgmt Group resources: SSH Key Management Guide · SSH Protocol and Certificate Authority Guide · OpenSSH Server Hardening Guide · PAM Buyer's Guide · Secrets Management Buyer's Guide