OpenSSH certificate auth flaws expose NHI blast radius in Linux fleets

At a glance

What this is: This is an analysis of a long-standing OpenSSH certificate authentication flaw that can turn crafted SSH certificates into unintended root access on Linux servers.

Why it matters: It matters because SSH certificate paths are non-human identities in practice, and a single misconfigured trust path can expand blast radius across CI/CD, bastions, and automation.

By the numbers:

• Cyera Research says the flaw has been present for over 15 years and was fixed this week.

👉 Read Cyera’s technical deep-dive on the OpenSSH certificate flaw

Context

SSH certificate authentication is a trust problem, not just a login mechanism. In this case, the issue is that one OpenSSH certificate path can misread principal content and accept access that was meant to be restricted, which is exactly the kind of failure that turns NHI governance into an operational risk.

The practitioner concern is broader than the bug itself. Linux fleets, bastion hosts, CI/CD systems, and custom SSH CA workflows often rely on certificate-backed access that behaves like a non-human identity, so a flaw in principal parsing can enlarge privilege unexpectedly. That starting position is common in environments that adopted SSH certificates gradually rather than centrally.

Key questions

Q: How should security teams govern SSH certificates in Linux environments?

A: Security teams should treat SSH certificates as privileged non-human identities and govern them with the same discipline used for service accounts and other machine access. That means strict issuance policy, validated principals, centralized trust anchors, and regular review of which hosts accept each certificate authority. The key control is limiting who can issue and where each certificate can authenticate.

Q: Why do SSH certificates create blast radius risk for NHI governance?

A: SSH certificates can be reused across many servers, so one weak trust path can expose an entire fleet. If certificate content is accepted differently by different hosts, the attack surface is shaped by identity scope rather than network boundaries. Teams should map reachable assets from each certificate-authenticated identity and reduce cross-environment reuse.

Q: What breaks when principal validation is weak in SSH certificate flows?

A: Weak principal validation can turn a restricted certificate into an unintended login path, including privileged access. The server may accept the certificate as valid even when the identity claim was malformed or overly permissive, which makes the failure hard to spot in logs. Teams should reject ambiguous claims before issuance and verify parsing consistency across hosts.

Q: What should teams do first after an OpenSSH certificate flaw is disclosed?

A: First, identify every affected server and isolate the trust paths that use the vulnerable configuration. Then rotate or revoke any certificate authority material that could have issued risky principals, and check which high-value systems were reachable through those paths. Containment should focus on trust scope before broader hardening work begins.

Technical breakdown

How OpenSSH principal parsing can bypass intended restrictions

OpenSSH certificates carry principals, which are identity claims that define where a certificate should be accepted. In the affected configuration, the cert-authority entry in authorized_keys can interpret a comma-separated principal string in a way that effectively splits the claim and matches an unintended value. That matters because the certificate still looks valid, so the server treats the authentication as legitimate rather than suspicious. The alternate TrustedUserCAKeys path in sshd_config does not behave the same way, which shows that trust placement and parsing path both matter. Practical implication: review where certificate trust is anchored, not just whether certificates are in use.

Practical implication: inventory every SSH certificate trust path and verify which parsing mode each server actually uses.

Why SSH certificates create NHI blast radius risk

SSH certificates are a form of NHI because they represent machine or automation access, not human logins. When one certificate authority can issue credentials across many servers, a single parsing flaw or weak issuance control can create fleet-wide exposure. The risk grows when certificates are reused across bastions, CI/CD runners, and automation accounts because principal-based authorization may allow a low-privilege issuance path to become a high-privilege server login. This is why SSH certificate governance must include issuance policy, principal validation, and trust-domain separation. Practical implication: treat certificate authority policy as access control, not just infrastructure plumbing.

Practical implication: separate issuance rules for automation, bastions, and admin paths so one certificate cannot span unrelated trust zones.

Why root access through SSH certificates is an identity governance failure

Root access is not just an endpoint privilege problem when it arrives through SSH certificates. It can expose databases, API tokens, cloud credentials, and secrets stored on the host, which means the compromise extends into other identity domains. Because the attack is a single SSH connection and may not register as a failure, detection based only on repeated login attempts will miss the real risk. NHI governance has to account for who can issue, who can present, and what downstream assets are reachable from that identity path. Practical implication: map certificate-authenticated identities to reachable data and credentials before an incident does.

Practical implication: build blast-radius mapping for SSH-authenticated identities and tie it to secrets and data exposure review.

Threat narrative

Attacker objective: The attacker’s objective is privileged SSH access that can be used to reach sensitive data and credentials across Linux servers.

1. Entry occurs when an attacker obtains or influences an SSH certificate with crafted principal content containing a comma.
2. Escalation occurs when the affected OpenSSH configuration interprets the principal in a way that bypasses the intended restriction and accepts the login as a different user, including root.
3. Impact occurs when the server grants privileged access that can expose databases, API tokens, cloud credentials, and other secrets stored on the host.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SSH certificates are non-human identities, and their governance failures now look like identity failures rather than infrastructure bugs. The article shows that a certificate trust path can turn into unintended root access when principal parsing is inconsistent. That is a governance problem because the identity claim, the issuance policy, and the trust anchor all have to align. Practitioners should model SSH certificates as privileged machine identities with explicit lifecycle control.

Principal validation is a control boundary, not a string-handling detail. If a CA can issue content that later gets parsed differently by the target host, then the effective access decision is split across two systems. That makes principal hygiene, rejection of malformed claims, and strict trust-path design essential. Practitioners should treat certificate content validation as part of authorization.

Identity blast radius is the right concept for this class of flaw. One certificate can be reused across many servers, so the damage is determined by where the trust path is accepted, not by where the flaw was discovered. That pushes teams toward reachability mapping, asset grouping, and certificate scoping. Practitioners should assess blast radius before they assess patch queues.

Incremental adoption of SSH certificates often leaves behind the governance controls needed to use them safely. The article’s affected environments include teams that layered certificates onto existing authorized_keys deployments rather than moving to centralized trust. That pattern usually preserves old assumptions about ownership and visibility. Practitioners should re-evaluate whether their SSH certificate rollout created hidden standing trust.

Access to Linux servers is now inseparable from secrets governance. Root on a server is valuable because of what lives there, including API tokens, certificates, and cloud credentials. That means SSH certificate policy belongs in the same governance conversation as secret handling and workload identity. Practitioners should tie SSH trust review to downstream data exposure review.

From our research:

• 57% of organisations lack a complete inventory of their machine identities, according to The Critical Gaps in Machine Identity Management report.
• 66% report that managing machine identities requires significantly more manual intervention compared to human identity management.
• For the broader control model, see NHI Lifecycle Management Guide and OWASP Non-Human Identity Top 10 for lifecycle and principal governance patterns.

What this signals

Principal governance is becoming a workload identity issue, not a niche SSH administration issue. As Linux access expands through certificates, bastions, and automation, teams need a named control boundary for who can issue credentials and which hosts accept them. The governance gap is not the patch itself, but the incomplete view of where machine identities live and what they can reach.

With 69% of organisations now having more machine identities than human ones, per The Critical Gaps in Machine Identity Management report, SSH certificate estates are no longer edge cases. Teams should expect certificate-driven access paths to be audited like any other non-human identity system, especially where root access can expose secrets.

Identity blast radius: the real control question is how far a certificate-authenticated identity can travel before it hits a trust boundary. That means access review, host grouping, and secrets mapping need to be linked in one operating model. Practitioners should prepare for blast-radius reporting to become a standard part of NHI governance reviews.

For practitioners

• Audit SSH certificate trust paths Identify every server using cert-authority entries in authorized_keys and compare them with systems using TrustedUserCAKeys in sshd_config. Prioritize bastion hosts, CI/CD runners, and environments that adopted SSH certificates incrementally.
• Validate principal handling at the CA Review certificate issuance policy so attacker-influenced principal content is rejected before issuance. Confirm that the CA enforces strict principal formats and does not permit commas or other ambiguous content in identity claims.
• Map blast radius from SSH-authenticated identities Document which databases, API tokens, cloud credentials, and secrets are reachable from each SSH certificate-authenticated path. Use that map to determine which hosts create the highest-impact exposure if root access is obtained.
• Move toward centralized trust anchors Where possible, standardize on a single trust model and remove mixed certificate handling across hosts. Mixed deployments increase the chance that parsing differences or partial migrations create inconsistent authorization behavior.
• Test detection for legitimate-looking privilege escalation Build monitoring around certificate issuance anomalies, unusual principal values, and high-risk login destinations rather than only failed SSH attempts. The attack path in this article can appear legitimate at the server layer.

Key takeaways

• OpenSSH certificate trust can fail as an identity control problem, not just a software defect.
• Machine identity inventory gaps make SSH certificate exposure harder to contain and easier to miss.
• Practitioners should validate principal handling, centralize trust, and map reachable secrets before the next disclosure.

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.
• Certificate Authority Trust Path: A certificate authority trust path is the route by which a server decides which signed SSH certificates it will accept. For machine identities, the trust path determines the blast radius of issuance mistakes and must be designed with consistent parsing and narrow scope.
• Identity Blast Radius: Identity blast radius is the set of systems, data, and credentials reachable when a non-human identity is compromised. It is a practical way to measure the downstream impact of SSH certificates, service accounts, or other machine credentials that can span multiple hosts.

Deepen your knowledge

SSH certificate governance and machine identity lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are dealing with bastions, CI/CD runners, or mixed SSH trust paths, it is worth exploring.

This post draws on content published by Cyera: A 15-Year Gap in SSH Security and What to Do About It. Read the original.