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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
