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