Here's a simple patch which retrieves authorized_keys via exec'ing a program, rather than reading a flat file. I added a simple option, AuthorizedKeysExec, to sshd_config which simply executes the respective file, passing the username as argv[1]. Keys are returned via stdout. Notes: If AuthorizedKeysExec is set and an authorized_keys file exists, checking the existing authorized_keys file takes precedence. I believe this to be a more simplistic and trivial patch to openssh opposed to the pre-existing patches, such as the popular LDAP patch (http://code.google.com/p/openssh-lpk/). Best, -- Michael J. Flickinger -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.diff Type: text/x-patch Size: 5655 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111214/437dbeba/attachment.bin>
On Wed, 14 Dec 2011 19:23:55 -0500, "Michael J. Flickinger" <mjflick at gnu.org> wrote:> Here's a simple patch which retrieves authorized_keys via exec'ing a > program, rather than reading a flat file.Hi, Michael. There are actually already some outstanding patches to support this behavior: https://bugzilla.mindrot.org/show_bug.cgi?id=1663 The approach above is similar to the one you are suggesting. Hopefully the existing patches would also work for you. Feel free to add to the discussion in the above bugzilla report. jamie. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111214/c7138d81/attachment.bin>
On 12/19/2011 03:49 PM, Peter Stuge wrote:> Michael J. Flickinger wrote: >> a clean and safe way to extend the authorized_keys functionality. > > How safe it is depends on what you execute I guess.You cannot really baby-sit the user though, they can already do unsafe things...
On 12/20/11 7:21 AM, Peter Stuge wrote:> Michael J. Flickinger wrote: >>>>>> a clean and safe way to extend the authorized_keys functionality. >>>>> >>>>> How safe it is depends on what you execute I guess. >>>> >>>> You cannot really baby-sit the user though, they can already do >>>> unsafe things... >>> >>> It's not about the user, but about root who runs sshd, and suddenly >>> requires even more clue in order to run a tight ship. >>> >>> I completely understand being conservative with adding hooks and >>> "plugins" in sshd. >> >> For what it's worth, the exec is not being run as root in that patch. > > This is good! It means that problems will affect users, and not the > full system, but still there can be problems which will affect users. > > > //PeterWell, I believe that patch lets you specify a user to run the exec... I'm not sure what can be done beyond that. For what it's worth, whoever is running the system could do something equally as bad with pam_exec.