Re: Certificates and authorized principals

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 




> On May 9, 2010, at 10:41 PM, Damien Miller <djm@xxxxxxxxxxx> wrote:
> 
> Hi,
> 
> Users who are interested in certificate authentication might be interested
> in this change:
> 
>> - djm@xxxxxxxxxxxxxxx 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux