On Mon, 19 Sep 2022, Brian Candler wrote:
> I have had the following potential inconsistency pointed out to me, and
> I thought I'd raise it here.
>
> On the one hand, OpenSSH by default doesn't allow authentication using
a
> certificate with no principals[^1]. From sshd_config(5):
>
> > Note that certificates that lack a list of principals will not be
> permitted for authentication using TrustedUserCAKeys.
>
> On the other hand, the spec at
>
https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL.certkeys?rev=1.19&content-type=text/x-cvsweb-markup
> says:
>
> > As a special case, a zero-length "valid principals" field
means the
> certificate is valid for any principal of the specified type.
>
> I think the behaviour of sshd is sane and sensible. A
> "super-certificate" which can impersonate any user (or any
host[^2])
> seems like a dangerous thing to me; especially since it's what you get
> by default if you omit the -n option to ssh-keygen -I.? There are other
> SSH CAs which may generate this sort of certificate if you don't
request
> any principal (e.g. Hashicorp Vault).? Rejecting it seems the safer option.
>
> I wonder if the protocol documentation is out of step, or if I've
missed
> a subtlety?
The no-principals case was intended to support user-specified (as
opposed to admin-specified) trust anchors. E.g. in ~/.ssh/authorized_keys
Certificates accepted by the system-wide TrustedCAKeys are required to
have a principal present.
> AFAICT, this allows anyone with *any* user certificate signed by the CA
> to authenticate, with or without principals. That's clearly less than
> ideal, but at least it was configured explicitly on this account, and
> the attack surface is limited to that one particular account.
Right, that's the use-case.
-d