SSH Certificate authentication should be configurable with a list of custom principals to authenticate

[tetofonta]

I'd be very glad if this plugin had the option to specify a list of principals to authenticate against, which differs from the hardcoded username currently in use.

This could improve freedom of configuration, for example giving access to a specific account with or without sudo privileges.

I could make a PR about this in the future, but i'd like to discuss a possible implementation. For example, off the top of my head, a principals file could be passed with PAM parameters, like what is being done with the authorized_keys file and others.
Whenever certificate verification is called, the plugin could load the list of principals from the specified file, maybe also including variable expansion at least for the username. Then the check is performed by verifying the presence of at least one of the principals in the file against the list of principals in the certificate.

[nresare]

Apologies for the late reply.

Am I correct in thinking that you would like to have implemented the princials parameter as decribed in the AUTHORIZED_KEYS FILE FORMAT in the sshd man page?

On a cert-authority line, specifies allowed principals for certificate authentication as a
comma-separated list. At least one name from the list must appear in the certificate's
list of principals for the certificate to be accepted. This option is ignored for keys that
are not marked as trusted certificate signers using the cert-authority option.

It should not be too complicated to add this feature

[nresare]

Having another think, I believe that feature as described would simply introduce another requirements on the usage of a specific cert-authority key.

I believe what you are looking for is a way to make a certificate be accepted even if the username of the authenticating user is not present in the list of valid principals. Is this correct? Something like an override_principals option for an cert-authority key.

I think a concrete example of a scenario when such a feature would be useful would be helpful.

[tetofonta]

Am I correct in thinking that you would like to have implemented the princials parameter as decribed in the AUTHORIZED_KEYS FILE FORMAT in the sshd man page?

I was looking more towards the behavior of sshd when TrustedUserCAKeys and AuthorizedPrincipalsFile are set but that option may also allow for greater elasticity in granting sudo access based upon different CAs, so yes, you are correct.

I believe what you are looking for is a way to make a certificate be accepted even if the username of the authenticating user is not present in the list of valid principals. Is this correct? Something like an override_principals option for an cert-authority key.

Yes, your second interpretation is correct.

What I am looking for is a way to decouple login identity from authorization. A user may need to log in as the same local account on multiple hosts, while certificate principals determine what level of access is granted on each host.

For example, jhon may need to log in as jhon on both Host A and Host B. Host A is an internal server he administers, so he should be allowed to obtain elevated privileges there. Host B is a production server, so he should only have limited non-privileged access for operational tasks such as checking service status, verifying deployments, and reading non-sensitive logs.

In that scenario, checking only for the username jhon in the certificate principals is too limiting. A more flexible model would allow additional principals such as root@host-a to grant elevated privileges on Host A, while still using jhon as the login identity on both hosts.

A certificate containing jhon and root@host-a would then allow login to both hosts as jhon, but elevated privileges only on Host A.

This is useful in multi-host environments because access can be granted by issuing a certificate, possibly with limited validity, without having to reconfigure each host for every user.

[tetofonta]

Are there any questions or progress being done on this? I can have a PR ready shortly if needed.