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?
What started this discussion[^3] was that in Go's implementation of ssh,
validating a certificate skips the principal check if the certificate
contains no principals - apparently in accordance with the spec.
https://cs.opensource.google/go/x/crypto/+/c86fa9a7:ssh/certs.go;l=401-413
Regards,
Brian.
[^1] Although I haven't tested it for a while, I was able to accept a
principal-less certificate, by adding an entry to ~/.ssh/authorized_keys
which specifies cert-authority without any principals="..." option.
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.
[^2] I haven't tested whether a host certificate without any principals
is accepted by the ssh client.
[^3] https://github.com/uber/pam-ussh/issues/15#issuecomment-1250245686
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
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?
What started this discussion[^3] was that in Go's implementation of ssh,
validating a certificate skips the principal check if the certificate
contains no principals - apparently in accordance with the spec.
https://cs.opensource.google/go/x/crypto/+/c86fa9a7:ssh/certs.go;l=401-413
Regards,
Brian.
[^1] Although I haven't tested it for a while, I was able to accept a
principal-less certificate, by adding an entry to ~/.ssh/authorized_keys
which specifies cert-authority without any principals="..." option.
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.
[^2] I haven't tested whether a host certificate without any principals
is accepted by the ssh client.
[^3] https://github.com/uber/pam-ussh/issues/15#issuecomment-1250245686
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev