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
On 9/19/22 20:57, Brian Candler wrote:> 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 cannot imagine any reasonable rationale for that.> 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;+1 In general a digital certificate is a signed statement by a CA saying: "This public key belongs to this name/ID. Trust me!" Thus if there's no name or ID in the certificate it's not a valid certificate.> I wonder if the protocol documentation is out of step,IMO yes. Ciao, Michael.
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