> 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