OpenSSH certificate principal confusion turns commas into root access

At a glance

What this is: This is a principal-escalation flaw in OpenSSH certificate authentication where a comma in a certificate principal can be split into multiple values and used to bypass an authorized_keys principals= restriction.

Why it matters: It matters because SSH certificate trust is often used to control privileged access, and a string-handling mistake can collapse least-privilege assumptions for machine and administrative identities.

Context

OpenSSH certificate authentication is meant to simplify SSH trust by moving authorization from per-host static keys to a certificate authority and short-lived user certificates. The security model depends on certificate principals being compared exactly, because principals are the identities a certificate is allowed to impersonate. In this article, the identity problem is not key compromise but principal matching inside the trust path.

Cyera says the vulnerable path is the authorized_keys cert-authority entry with a principals= restriction, where OpenSSH used a list-matching helper instead of exact string comparison. That means a single principal string containing a comma could be treated as two values during authorization, even though the certificate format stores it as one opaque principal. The issue is a governance failure in how SSH trust decisions are evaluated, not a cryptographic failure in certificate signing.

Key questions

Q: What breaks when OpenSSH certificates are authorized through principals= entries?

A: The failure is exact principal matching. In the affected path, OpenSSH used a list parser where it should have compared the certificate principal as one opaque string, so a comma inside the principal could be treated as a separator and widen the allowed identity.

Q: Why can a comma in an SSH certificate principal create privilege escalation risk?

A: Because commas are delimiters in list parsing, not in identity semantics. If the authorization code splits one principal into fragments, a certificate issued for a scoped user can be misread as matching a privileged name such as root, which turns scoping into escalation.

Q: What do security teams get wrong about SSH certificate trust paths?

A: They often assume that certificate validity alone proves authorization is correct. In reality, the trust path must preserve the exact principal string from issuance through server-side evaluation, otherwise a parsing bug can defeat least privilege even when the signature is valid.

Q: When should organisations re-evaluate principals= based SSH access controls?

A: They should re-evaluate them whenever CA-signed user certificates are accepted through per-key authorized_keys trust, especially for privileged accounts. That is the point where exact identity comparison, CA policy, and key-option parsing all need to line up.

Technical breakdown

How comma splitting broke principal matching

The vulnerable code used match_list() to compare a certificate principal against the server-side principals= option. match_list() is designed for comma-separated negotiation lists, so it splits both sides on commas before comparing items. That is correct for algorithm selection, but wrong for authorization because a certificate principal is supposed to be an opaque identity string. When deploy,root is treated as a list, the helper can match root even though the actual principal is not exactly root. The bug is therefore a data-model mismatch: a list parser was reused in an identity-checking path.

Practical implication: treat certificate principals as exact identity strings, not list fields, in authorization logic.

Why the vulnerable trust path skipped the second check

OpenSSH had a safer principal-checking path elsewhere in the code, but the affected authorized_keys cert-authority flow passed NULL into the later authority function when principals= was configured. That suppressed principal comparison in the second stage and made the earlier match_principals_option() decision effectively authoritative. In other words, once the comma-split fragment matched the allowed token, the downstream check no longer re-validated the original principal string. The failure was not just a bad helper call, but a broken control sequence where one check replaced another.

Practical implication: review multi-stage authorization paths for places where an initial parsing decision disables later identity validation.

Why ssh-keygen could not create the dangerous principal directly

The exploit needed a certificate with one principal string containing a comma, but ssh-keygen -n treats commas as separators when building the certificate. So -n "deploy,root" produces two principals, deploy and root, not one comma-containing principal. The article shows that a payload had to be crafted with a custom certificate generator that writes one length-prefixed principal value containing the comma. That distinction matters because the attack depends on the certificate format preserving the comma while the server-side matcher misreads it as a delimiter.

Practical implication: validate both certificate generation rules and server-side parsing assumptions when assessing exploitability.

Threat narrative

Attacker objective: Obtain SSH access as a more privileged account than the certificate was meant to authorize, including root.

1. Entry occurs when an attacker obtains a CA-signed SSH certificate trusted through a vulnerable authorized_keys cert-authority entry with principals=.
2. Credential access is not the issue here because the attacker already has a valid certificate, but the certificate contains a principal string with a comma that the server will misparse.
3. Escalation happens when match_list() splits deploy,root and matches the root fragment against the allowed principal token, allowing authentication as a higher-privilege account.
4. Impact is a successful SSH session as the target account, including root when the affected trust line protects the root user.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

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

Exact string comparison is a governance requirement, not an implementation detail: SSH certificate principals are identity assertions, so the authorization check must compare the full principal exactly. Reusing a list-matching helper for an authorization decision collapses the meaning of identity from one opaque string into a split token stream. The practical lesson is that trust models fail when identity parsing and identity authorization are allowed to share the same code path.

Comma-splitting creates identity ambiguity at the point least privilege is supposed to hold: The principals= option is intended to scope a certificate to a narrow login identity, but the vulnerable matcher widened that scope by interpreting one principal as multiple values. This is a classic trust-boundary failure in NHI governance, where the certificate itself remains valid yet the authorization semantics drift. The takeaway for practitioners is that principal handling must preserve the certificate’s original granularity.

Short-lived certificates do not eliminate authorization flaws in the trust path: SSH certificates can reduce key sprawl, but they do not protect against logic errors in principal validation. The model still depends on deterministic evaluation of who a certificate may impersonate, and a single parser bug can turn scoped access into administrative access. Practitioners should treat certificate trust logic as part of privileged access governance, not merely as transportable authentication plumbing.

SplitSSHell is a useful named concept for the category’s failure mode: a single delimiter character can split one principal into several identities and collapse least privilege at the authorization layer. That is a reminder that machine identity controls fail not only through theft or over-issuance, but through incorrect interpretation of the identity payload itself. The control objective is to preserve identity boundaries exactly as issued.

Authorized_keys certificate trust exposed a standing privilege assumption that should not have existed: The vulnerable path effectively assumed that one server-side token comparison was enough to prove principal legitimacy. That assumption fails when the certificate principal can be reinterpreted during parsing, because the authorization decision no longer evaluates the same identity string that was issued by the CA. Practitioners should re-examine every place where certificate policy is enforced through ad hoc string handling.

What this signals

Comma-sensitive identity handling is a persistent governance fault line: SSH certificates only work when the server evaluates the same principal string the CA issued. Once a parser is allowed to reinterpret that string, the access model no longer expresses least privilege reliably, and the programme has a hidden authorization boundary problem.

The broader lesson is that certificate-based access control needs more than strong cryptography and short-lived credentials. If principal comparison, trust configuration, and privileged account policy are not aligned, an attacker does not need to break the certificate to break the decision.

SplitSSHell names the failure precisely: one delimiter character can fracture identity semantics inside an authorization check. That matters for NHI governance because the weakest point is often not issuance, but the exact way a platform interprets the issued identity at runtime.

For practitioners

• Harden certificate principal comparison Review SSH certificate authorization code and configuration paths so that certificate principals are compared with exact string equality, not list helpers that split on commas or other delimiters.
• Inventory principals= trust lines Search authorized_keys for cert-authority entries that use principals= and identify any environment where CA-signed user certificates are accepted through per-key trust instead of centralized principal policy.
• Test malformed principal inputs Validate how your SSH trust path handles principals that contain commas, whitespace, or other separator characters, then confirm the server rejects anything that is not an exact principal match.
• Limit root certificate authorization Avoid relying on a single principals="root" restriction for privileged SSH access unless the full certificate lifecycle, CA policy, and server-side matching logic have all been verified.
• Patch affected OpenSSH versions Upgrade systems running affected OpenSSH releases to the fixed 10.3 or 10.3p1 line and treat the principal-matching defect as an authorization bug, not a cryptography bug.

Key takeaways

• The article shows that a parsing error in OpenSSH certificate authorization can turn a scoped principal into a privileged login path.
• The vulnerability affected OpenSSH 5.6 through 10.2p1 and was fixed in 10.3 or 10.3p1, with impact reaching root access when the trust path and CA policy align.
• Exact string comparison for certificate principals is the control that would have preserved the intended identity boundary and prevented the escalation.

Key terms

• SSH Certificate Principal: An SSH certificate principal is the identity string or strings a signed SSH user certificate is allowed to authenticate as. In a correct design, it must be compared exactly, because changing how it is parsed can widen access beyond the issuer’s intended scope.
• Cert-Authority Trust Path: A cert-authority trust path is an SSH configuration pattern where a server trusts certificates signed by a specific CA instead of storing each user key directly. It centralises trust and lifecycle control, but it also makes CA policy, parsing, and verification logic part of the security boundary.
• Principal Matching: Principal matching is the authorization step that checks whether a presented SSH certificate is allowed to log in as the requested account. For SSH certificates, it must preserve the original principal value exactly, otherwise delimiters, list helpers, or token splitting can create unintended matches.
• Authorization Boundary: The authorization boundary is the defined scope of systems, identities, and dependencies that must satisfy a compliance programme. In FedRAMP, it determines what the assessor evaluates and what must be documented as external, so boundary accuracy is a control decision, not a paperwork exercise.

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.