On 19/02/21, Brian Candler (b.candler@xxxxxxxxx) 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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
