Topic starter
02/06/2026 7:00 pm
TL;DR: A principal-escalation flaw in OpenSSH certificate authentication let a comma inside one certificate principal be treated as a separator, so a CA-signed identity such as deploy,root could satisfy a principals="root" restriction, according to Cyera Research. The issue shows how trust-path details, not cryptography, can decide whether SSH certificates preserve least privilege.
Editorial analysis by NHI Mgmt Group, based on content published by Cyera: “SplitSSHell - When a Comma Becomes Root How a Single Character Broke OpenSSH Certificate Authentication”.
Key questions
Q: What breaks when OpenSSH certificates are authorized through principals= entries?
A: The failure is exact principal matching.
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.
Q: What do security teams get wrong about SSH certificate trust paths?
A: They often assume that certificate validity alone proves authorization is correct.
Practitioner guidance
- 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.
Bottom line: The article shows that a parsing error in OpenSSH certificate authorization can turn a scoped principal into a privileged login path.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/06/2026 7:16 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: OpenSSH certificate principal confusion turns commas into root access