TL;DR: A crafted SSH certificate can bypass principal restrictions in affected OpenSSH configurations and grant unintended access, including root, with a single connection, after a flaw present for more than 15 years, according to Cyera research. SSH certificate paths therefore create NHI blast radius that extends well beyond authentication and into fleet-wide data exposure.
At a glance
What this is: Cyera Research identifies an OpenSSH certificate authentication flaw that lets a crafted certificate bypass principal restrictions and obtain unintended access, including root, on affected Linux servers.
Why it matters: IAM, PAM, and NHI teams need to treat SSH certificate authentication as a governed identity path, because one malformed certificate can widen access across fleets and expose downstream secrets.
Context
OpenSSH certificate authentication is a non-human identity control because it determines which machine or operator identity can reach which Linux host under what trust conditions. In the affected configuration, the parsing of certificate principals in authorized_keys can transform a narrow trust path into broader access than the CA intended.
The governance gap is not only that a bug existed for 15 years. It is that organisations often treat SSH certificates as a deployment convenience rather than a lifecycle-controlled identity plane, especially when cert-authority entries are added incrementally across bastions, CI/CD systems, and custom CA workflows.
For practitioners, the issue sits at the intersection of remote access, certificate lifecycle, and privilege scope. If the principal boundary is misread, the resulting access decision can be legitimate to the server while still being invalid from an identity governance perspective.
Key questions
Q: What breaks when SSH certificates rely on ambiguous principal parsing?
A: The trust decision can stop reflecting the issuer's intent. If a certificate principal is parsed differently than it was issued, one identity string can be interpreted as multiple allowed identities, which can let an attacker authenticate as an unintended user. That turns certificate validation into a governance failure, not just a parsing bug.
Q: Why do SSH certificate authentication flaws create fleet-wide risk?
A: A single trusted CA can be accepted on many servers, so one malformed certificate may work wherever the same principal-matching rules are used. The risk scales with shared trust, not just with the vulnerable host. That is why SSH certificate paths need fleet-level inventory and revocation discipline.
Q: What are the signs that SSH certificate trust is too broad?
A: Look for cert-authority entries spread across many authorized_keys files, inconsistent principal formats, and administrative access paths that reuse the same CA for multiple tiers. Those patterns show that one certificate could authenticate in more places than the organisation expects, which increases blast radius.
Q: How should organisations respond when a privileged SSH certificate path is flawed?
A: Disable or constrain the affected trust pattern first, then search for any privileged accounts that rely on it. Rotate the CA or any signing workflow that may have issued ambiguous principals, and move sensitive access to a configuration path that uses exact principal comparison. Treat the issue as an authorization exposure, not just a software patch event.
Technical breakdown
How a crafted SSH certificate bypasses principal checks
OpenSSH certificates carry principals, which are the identities the certificate is allowed to represent. In the affected cert-authority path in authorized_keys, a comma inside a principal can be interpreted as a separator rather than a literal character, so a crafted value can be parsed into multiple principals. If one of those parsed values matches a permitted principal, authentication succeeds even though the CA may have intended a narrower identity binding. The critical point is that the trust decision is made from parsed content, not just from the issuer or the certificate format.
Practical implication: Validate where principal parsing occurs and remove certificate acceptance paths that depend on ambiguous principal interpretation.
Why cert-authority deployments widen NHI blast radius
The flaw matters most where the same CA is trusted across many servers through authorized_keys entries. In that model, one issued certificate can travel across the fleet wherever the principal fragment matches local trust rules. This is not just a single-host authentication bug. It is a machine identity propagation problem, because a certificate with a valid issuer can be reused wherever the trust relationship and principal matching align. That turns one access mistake into a fleet-wide exposure pattern.
Practical implication: Map every host that trusts the same SSH CA so you can see where one certificate could legitimately authenticate.
Why root access is the real identity failure mode
The dangerous outcome is not merely login success. The article states that exploitation can grant access as an unintended user, including root, and that server-side logging may not flag the event as failed authentication. That means the identity plane itself becomes the control failure, not the network perimeter or a noisy exploit chain. Once root is obtained, the host becomes a collection point for secrets, API tokens, and cloud credentials, which converts an SSH parsing flaw into a broad compromise of downstream non-human identities and data access paths.
Practical implication: Treat root-capable SSH certificate paths as privileged identity routes and restrict them to configurations with unambiguous certificate validation.
Threat narrative
Attacker objective: Obtain privileged SSH access to Linux hosts and use that access to reach host-resident secrets and broader infrastructure credentials.
- Entry occurs when an attacker obtains a certificate with a crafted principal that includes a comma and uses a single SSH connection against an affected host.
- Credential access follows when the CA or server accepts the malformed principal content and the certificate is treated as a valid authentication artifact.
- Escalation occurs when principal parsing matches an unintended identity, allowing the session to be established as a higher-privilege account, including root.
- Impact follows when the authenticated host exposes databases, API tokens, cloud credentials, and other secrets stored on the server.
Breaches seen in the wild
- SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
SSH certificate authentication is a governed NHI trust path, not a convenience feature. The article shows that one certificate can expand access across Linux fleets when principal parsing and CA trust are loosely defined. That is a governance problem because the certificate represents an identity decision, not just a transport mechanism. Practitioners should treat SSH certificate trust as part of the non-human identity lifecycle, with explicit ownership and revocation boundaries.
Principal parsing ambiguity creates identity blast radius. The vulnerable cert-authority path demonstrates that the meaning of a principal is as important as the presence of a certificate. If a parser can reinterpret one identity string as multiple allowed identities, the access decision no longer reflects the issuer's intent. The implication is that identity policy must account for how trust material is interpreted at runtime, not only how it is issued.
Fleet-wide SSH CA trust is a hidden privilege aggregation layer. When many servers accept the same CA, the CA becomes a central authority for remote access across the environment. That centralisation is useful, but it also means a single malformed certificate can inherit broad reach wherever local principal rules align. Practitioners should recognise SSH CA trust as a blast-radius control point, not just an authentication shortcut.
Root access through SSH certificates collapses the separation between authentication and downstream secret exposure. Once an attacker reaches root on a host, the issue is no longer limited to login. Host-resident credentials, keys, and tokens become reachable assets, which means the real control boundary is the set of privileged identities that the host can expose. That should push teams to model SSH certificate paths as part of identity and data governance together.
Machine identity governance must include certificate parsing assumptions. The named concept here is principal trust ambiguity: when certificate identity strings can be interpreted differently by issuance and verification logic. That assumption breaks the moment a crafted principal is accepted as two identities instead of one. The implication is that identity governance cannot stop at certificate issuance and rotation; it must also validate how relying services resolve identity claims.
What this signals
Principal trust ambiguity: The real control failure is not simply that SSH certificates exist, but that relying services may interpret the same principal string differently from the CA that issued it. When that happens, access policy becomes a parsing problem, and parsing problems are governance problems in disguise.
When SSH certificate trust is reused across bastions, CI/CD systems, and custom CA workflows, the CA becomes a high-value identity control plane. Teams should model that path like any other privileged access route, because the compromise impact extends to host-resident secrets and downstream credentials.
For practitioners
- Harden certificate principal validation Review every SSH CA workflow for comma-sensitive principal handling and reject ambiguous principal content before it reaches authorized_keys trust decisions.
- Inventory CA trust across fleets Map all Linux servers that trust the same SSH certificate authority through cert-authority entries so you can see where one certificate could authenticate.
- Prioritise root-capable SSH paths Separate privileged administrative access from general remote access and remove root-adjacent SSH certificate use where certificate parsing is not fully deterministic.
- Rotate and revoke issued certificates Invalidate certificates issued through any CA or issuance flow that could have produced crafted principals, then reissue under a validated principal policy.
Key takeaways
- OpenSSH certificate authentication can fail as an identity governance control when principal parsing allows unintended users to pass as authorised identities.
- The blast radius is larger than a single host because the same CA trust can apply across many Linux servers and administrative workflows.
- The control gap is principal ambiguity in the certificate trust path, which means validation and revocation need to be treated as part of SSH identity governance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The flaw is an SSH certificate authentication failure that allows unintended identity acceptance. |
| NHI-05 — Overprivileged NHI | A crafted certificate can escalate into root, showing excess privilege on a non-human identity path. | |
| NHI-07 — Long-Lived Secrets | Reusable certificates and CA trust make the exposure persistent across many hosts until revoked. | |
| Recommendation — Validate SSH certificate authentication paths for ambiguous principal handling and reject malformed identity claims. Reduce SSH certificate privilege scope so unintended certificate acceptance cannot reach root-level access. Shorten SSH certificate validity and revoke any trust material that could be reused across the fleet. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SSH certificates are authenticators whose lifecycle and validation are directly governed here. |
| Recommendation — Apply IA-5 to govern SSH certificate issuance, validation, and revocation across Linux fleets. | ||
| MITRE ATT&CK | TA0006; TA0004; TA0040 — Credential Access; Privilege Escalation; Impact | The article describes credential-based access leading to privilege escalation and host-level impact. |
| Recommendation — Map affected SSH certificate paths to credential access and privilege escalation techniques to prioritise detection. | ||
Key terms
- SSH Certificate: An SSH certificate is a signed credential that lets a server trust an identity without relying on a static key alone. In NHI terms, it is a short-lived machine credential whose security depends on issuance policy, principal validation, and where the trust anchor is accepted.
- Principal: A principal is the identity claim inside a certificate that says where and by whom the credential should be accepted. In this context, principal handling is a control point because malformed or ambiguous content can change the effective authorization decision.
- Cert-Authority Entry: An authorized_keys trust entry that tells a server which certificate authority may issue SSH certificates it should accept. It is a local trust policy, and when deployed across many hosts it becomes a fleet-wide access control boundary.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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 programme, it is worth exploring.
Published by the NHIMG editorial team on June 2, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org