Fix for openssh 10.13 breaking principals wildcard in SSH certificates

[EthanHeilman]

OpenSSH 10.3/10.3p1 made a backwards compatibility breaking change that may be causing OPKSSH certificates to fail.

  * sshd(8): prior to this release, a certificate that had an empty
   principals section would be treated as matching any principal
   (i.e. as a wildcard) when used via authorized_keys principals=""
   option. This was intentional, but created a surprising and
   potentially risky situation if a CA accidentally issued a
   certificate with an empty principals section: instead of being
   useless as one might expect, it could be used to authenticate as
   any user who trusted the CA via authorized_keys. [Note that this
   condition did not apply to CAs trusted via the sshd_config(5)
   TrustedUserCAKeys option.]

   This release treats an empty principals section as never matching
   any principal, and also fixes interpretation of wildcard
   characters in certificate principals. Now they are consistently
   implemented for host certificates and not supported for user
   certificates.

https://www.spinics.net/lists/openssh-unix-dev/msg10392.html

This breaks OPKSSH, because OPKSSH relies on the wildcard behavior of the empty principal in user SSH certificates.

OPKSSH:

1. Issues a user an SSH certificate containing user identity attestations about the user.
2. User sshes as a particular principal with the SSH certificate. The SSH certificate is sent to an AuthorizedKeysCommand that reads identity attestations along with the desired principal from the SSH session and checks if OPKSSH policy allows that identity to assume that principal.

Because we don't know the desired principal at ssh certificate issuance time and the user may use the certificate for multiple principals, we must rely on the principal flag being empty as a wildcard.

The fix

Gemini 3 pro proposed the following fix.

1. Set the principal in the SSH cert to a dummy value of opkssh-wildcard, rather than leave it empty. This prevents newer versions of OpenSSH from automatically failing the SSH cert for having an empty principal.
2. Have opkssh verify return cert-authority,principals="opkssh-wildcard" <ca-key> instead of cert-authority <ca-key>. Setting principals in the response short circuits sshd's check that principal matches the linux username the user is attempt to assume. The reason you can put principals in the response is that AuthorizedKeysCommand output is treated as an AuthorizedKeys file and AuthorizedKeys files have this behavior.

This fix allows SSH certificates to function as a wildcard again. Very clever Gemini.

[Copilot]

Pull request overview

This PR updates OPKSSH’s SSH certificate issuance/verification behavior to remain compatible with OpenSSH >= 10.3, which no longer treats empty certificate principals as a wildcard.

Changes:

• Issue user SSH certificates with a non-empty “sentinel” principal instead of an empty principals list.
• Update verify (AuthorizedKeysCommand output) to emit an authorized_keys line that includes a principals="..." option derived from the certificate principals.
• Adjust the verify unit test to expect the new principals="..." output format.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 6 comments.

File	Description
commands/verify.go	Adds principals handling in AuthorizedKeysCommand output to support the sentinel-principal approach.
commands/verify_test.go	Updates expectation to include principals="guest,dev" in the returned authorized_keys line.
commands/login.go	Changes issued cert principals from empty to a sentinel value (opkssh-wildcard).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.