User certificates with empty principals?

[Rory Campbell-Lange]

On 19/02/21, Brian Candler (b.candler at pobox.com) wrote:
> I wonder if you could help clarify something for me.  There is a scary
> warning in ssh-keygen(1) about certificates with empty principals:
> 
> "By default, generated certificates are valid for all users or hosts"
> 
> However, this appears to be contradicted by sshd_config(5), where it says:
> 
> "The default [for AuthorizedPrincipalsFile] is none, i.e. not to use a
> principals file - in this case, the username of the user must appear in a
> certificate's principals list for it to be accepted."
> 
> and:
> 
> "Note that certificates that lack a list of principals will not be permitted
> for authentication using TrustedUserCAKeys."
> 
> I've been trying to identify when a user certificate with no principals can
> be used, and the only case I can find is when the cert-authority has been
> listed in ~/.ssh/authorized_keys without a principals="..." option being
> specified.  Is that the only case? Including all older versions of sshd?
> 
> The reason I'm concerned is I'm looking at Vault for issuing SSH certs, and
> I've found that even if you constrain an SSH role to issue certs for a
> certain set of principals, it still lets the user issue a cert with no
> principals.  I'm trying to convince myself whether or not that's safe.
> 
> I have tested the scenarios I can think of with openssh 8.2p1:
> 
> 1. default configuration with no AuthorizedPrincipalsFile/Command
> 
> => sshd rejects with: "Certificate lacks principal list"
> 
> 2. AuthorizedPrincipalsFile containing "foo"
> 
> => sshd rejects with: "Certificate does not contain an authorized principal"
> 
> 3. empty AuthorizedPrincipalsFile
> 
> => sshd rejects with: "Certificate does not contain an authorized principal"
> 
> So it seems OK, but in that case perhaps ssh-keygen(1) could be clarified. 
> As well as the warning given above, it contains an example of creating a
> user certificate without any principals:
> 
>            $ ssh-keygen -s /path/to/ca_key -I key_id /path/to/user_key.pub
> 
> To me it seems not very useful (or safe), if the only way you could use it
> is to allow logins with *any* certificate from this CA in
> ~/.ssh/authorized_keys.

I've tested the scenarios you have outlined above on SSH 7.9p1 (Debian)
and have the same results.

I agree that the example for ssh-keygen would ideally be improved so
that the first signing example has a principal list so that this is
considered the default.

The possibility of someone "stealing" the server's TrustedUserCAKeys key
and inserting it into a user's ~/.ssh/authorized_keys file as a
cert-authority line hadn't occurred to me. Locking down the
AuthorizedKeysFile paths seem sensible, together will a policy for
rotating TrustedUserCAKeys frequently.

Can one not configure vault to never issue certificates without a
principals list? If not perhaps Hashicorp can be persuaded to add the
option.

Rory