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