Certificates and authorized principals

[John Devitofranceschi]

> On May 9, 2010, at 10:41 PM, Damien Miller <djm at mindrot.org> wrote:
> 
> Hi,
> 
> Users who are interested in certificate authentication might be interested
> in this change:
> 
>> - djm at cvs.openbsd.org 2010/05/07 11:30:30
>>   [auth-options.c auth-options.h auth.c auth.h auth2-pubkey.c key.c]
>>   [servconf.c servconf.h sshd.8 sshd_config.5]
>>   add some optional indirection to matching of principal names listed
>>   in certificates. Currently, a certificate must include the a user's name
>>   to be accepted for authentication. This change adds the ability to
>>   specify a list of certificate principal names that are acceptable.
>> 
>>   When authenticating using a CA trusted through ~/.ssh/authorized_keys,
>>   this adds a new principals="name1[,name2,...]" key option.
>> 
>>   For CAs listed through sshd_config's TrustedCAKeys option, a new config
>>   option "AuthorizedPrincipalsFile" specifies a per-user file containing
>>   the list of acceptable names.

Has anyone considered somewhat reversing the sense of this?  That is, allowing 
operators to use a "special” AuthorizedPrincipalsFile (call it “self”) that would have 
a collection of principals in it that would allow users to login as themselves in the 
absence of any other authorization mechanism?

As an example, given a host named “mirkwood”, the “self" authorized principals 
file would have a principal in it called “mirkwood_users” (possibly others). 
Anyone with that principal listed in their (valid) certificate would then be authorized 
to login to mirkwood as the login name they are using on the source system, provided
that the login name is *also* a valid principal in the certificate.

In this way, users can obtain access to a host without needing to modify anything
on the host itself or any other external namespace groups.

The specific use case I was thinking about has to do with issuing short-lived 
certificates that allow a user emergency access to a host. The openssh CA could 
then be more of a one-stop-shop for this kind of access, instead of having to 
deal with the host’s pam_access other authorization mechanism to permit the 
user to login.

jd

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2393 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20180105/5ca13b86/attachment.p7s>