Abusing an SSH Certificate Authority

Besides individual keys in authorized_keys, SSH supports a certificate model: a Certificate Authority (CA) signs user keys, and the server trusts any key signed by that CA (TrustedUserCAKeys in sshd_config). It's convenient at scale (no need to distribute authorized_keys), but the CA's private key is a master key: whoever holds it can sign themselves a certificate for any principal (any user), including root.

If during post-exploitation we find a CA's private key (a file like ca-itrc, test.key...), the attack is direct. We generate a keypair and sign the certificate, stating the principal we want to impersonate with -n:

ssh-keygen -t rsa -b 2048 -f keypair                       # our own keypair
ssh-keygen -s ca-itrc -I attacker -n zzinter keypair.pub   # sign for the "zzinter" principal
ssh -i keypair -o CertificateFile=keypair-cert.pub zzinter@localhost

The server checks that the certificate is signed by a trusted CA and that the principal is allowed, and lets us in with no password or prior key for the target user. Repeating with -n root (if the CA is authorized for that principal) jumps straight to root.

Caveats that matter.

• The principal must match what the server expects (AuthorizedPrincipalsFile or the username). On a real target you must discover which principals each CA accepts.
• Some deployments keep a revocation list (RevokedKeys) by serial number; there you should pin a specific serial with -z <n> that isn't revoked.
• A "decommissioned" but still trusted CA is exactly the flaw: it should have been removed from TrustedUserCAKeys and wasn't, so its signatures remain valid.

How to detect it. In the sshd log, the signature is an Accepted publickey that mentions a certificate (ID <...> (serial <n>) CA <type> <fingerprint>), and specifically one for a privileged principal (root, an admin) whose serial isn't in the CA's legitimate issuance record: that gives away an unauthorized signature. On the host, use of ssh-keygen -s <CA-key> (certificate creation) by an account that isn't the issuing authority (auditd over execve) is the other end. Very long-lived certificates or unexpected principals per CA are audit indicators.

Defence. Protect the CA key like the most sensitive secret (HSM, isolated host); use short-lived certificates; restrict principals per CA; maintain and review the revocation list; and remove from trust any CA you decommission.