cert-authority handling in authorized_keys broken

[Ashutosh Ghosh]

Hi all,

I was not able to find a suitable workaround that is either forwards 
compatible or backwards compatible. Currently I am having users hold 
off on upgrading to MacOS 26.6 but that's a ticking time bomb.

I think this should be revisited as a third party application misusing 
or misunderstanding the usage of the principals field shouldn't require 
all the applications that used it according to the documentation to handle 
the backwards incompatible change.

I think this will get more attention as users upgrade to OpenSSH >10.3 
and get surprised by this.  PROTOCOL.certkeys [1] explicitly recommended an
empty list as recently as 2025 when I went through the documentation (the
IETF doc that succeeds it does not have the same language though).

Can the options or extensions components of the certificate instead be 
used to opt-into the new validation scheme? Also I think the blast radius
in the vulnerability referenced by the change [2] is very different between
user and host certificates and that should factor into this decision.

Cheers,
Ashutosh

[1] https://github.com/openbsd/src/blob/dd9c8bcc13e769a7b6a39e64552782646e1c0f64/usr.bin/ssh/PROTOCOL.certkeys#L176
[2] https://nvd.nist.gov/vuln/detail/cve-2024-7594

________________________________________
From: openssh-unix-dev <openssh-unix-dev-bounces+ashutosh=g4es.org at mindrot.org> on behalf of Damien Miller <djm at mindrot.org>
Sent: Thursday, 10 September 2026 00:35
To: Kegan Myers <kegan at keganmyers.com>
Cc: openssh-unix-dev at mindrot.org <openssh-unix-dev at mindrot.org>
Subject: Re: cert-authority handling in authorized_keys broken
 
On Wed, 9 Sep 2026, Kegan Myers via openssh-unix-dev wrote:

> Anyone have thoughts or suggestions on this? Re-issuing all of the certs that
> are in use and working for hosts on older versions of openssh is a substantial
> effort.
>
> Is there any chance of revisiting this issue, at least for this specific usage
> pattern?

Theere was a thread on this a couple of weeks ago here where another
user affected by this change found a workaround, iirc involving
wildcards.

Wrt revisiting, no. The old behaviour was failure prone and resulted in
at least one vulnerability in a third-party application.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev