Hello everybody, I'd like to have LPK (or something like that - getting public keys from LDAP) integrated into mainline OpenSSH. *** First of all, a summary. The project page at http://code.google.com/p/openssh-lpk/ mentions that a few distributions include LPK per default; but reading the various threads at Support for merging LPK and hpn-ssh into mainline openssh? http://marc.info/?l=openssh-unix-dev&m=123483016220368&w=2 and Support for merging LPK into mainline openssh? http://marc.info/?l=openssh-unix-dev&m=125655418812760&w=2 I get the impression that the most important argument is this one, citing Damien Miller (http://marc.info/?l=openssh-unix-dev&m=125252189630862&w=2):> Because the API presented by the LDAP libraries that I have looked at is > quite ugly, because different platforms have different favourite LDAP > APIs, because we don't want to build in support for every crazy variant > schema that people will inevitably come up with.Regarding the other way, ie. using another process, (from the same mail)> On Wed, 9 Sep 2009, Howard Chu wrote: > > Hmm. Pushing this out to a separate process requires inventing yet > > another IPC protocol, and adds one more moving piece that can break. > > How does this approach avoid complexity? > > It avoids complexity in the critical part - the sshd daemon. It is more > orthogonal too - if someone wants to store keys in xyzdb then they can > make a subprocess to do that too.there's another catch:> > One thing that would be good is having some sort of signing mechnanism > > on the Agent. As I see you check to make sure the ownership of the > > file is ok. > > > > How about another approach is to sign the Agent with the servers > > private key (if that's possible??). > Maybe may be included SHA hash of agent program in the config file > and it may be checked before running the agent. But it is necessary? > and who will check all the shared libraies used?*** Brainstorming So, given that arguments, I'd like to offer a few ideas that might help. 1) How about loading some shared library (libraries) for retrieving public keys? The library would provide interfaces like an init(), uninit(), and lookup(). Lookup would get the username and public key, and return a string describing the login options ("environment=...") or NULL for no public key found. Alternatively it could provide a function for returning a list of public keys, but I think doing a single lookup would be better. 2) If a separate process is the better way, how about skipping the signature idea and instead provide the same level of securiy as sshd itself? Just open two pipes (STDIN, STDOUT) to an external program started on sshd startup, use them for communication, and if the handles ever get closed just log an error and don't use them anymore. So if the external program gets changed on disk it wouldn't matter (or at least, only as far as changing /usr/sbin/sshd would, too). 3) The other idea I heard (but more of a joke, I think) was to use FUSE to provide the public keys from LDAP. I'd like all interested parties to participate in this thread, to get a discussion going, and get an approximate level of community interest. Thank you for all answers. Regards, Phil
There's long history of using external commands as an extensibility point (ProxyCommand for example) and, if there was going to be any way of linking LDAP in, this would almost certainly be the best way. On Wed, Jun 9, 2010 at 4:18 AM, Philipp Marek <philipp.marek at linbit.com>wrote:> Hello everybody, > > I'd like to have LPK (or something like that - getting public keys from > LDAP) integrated into mainline OpenSSH. > > > *** First of all, a summary. > > The project page at > > http://code.google.com/p/openssh-lpk/ > > mentions that a few distributions include LPK per default; but reading the > various threads at > > Support for merging LPK and hpn-ssh into mainline openssh? > http://marc.info/?l=openssh-unix-dev&m=123483016220368&w=2 > > and > > Support for merging LPK into mainline openssh? > http://marc.info/?l=openssh-unix-dev&m=125655418812760&w=2 > > I get the impression that the most important argument is this one, citing > Damien Miller (http://marc.info/?l=openssh-unix-dev&m=125252189630862&w=2 > ): > > Because the API presented by the LDAP libraries that I have looked at is > > quite ugly, because different platforms have different favourite LDAP > > APIs, because we don't want to build in support for every crazy variant > > schema that people will inevitably come up with. > > Regarding the other way, ie. using another process, (from the same mail) > > On Wed, 9 Sep 2009, Howard Chu wrote: > > > Hmm. Pushing this out to a separate process requires inventing yet > > > another IPC protocol, and adds one more moving piece that can break. > > > How does this approach avoid complexity? > > > > It avoids complexity in the critical part - the sshd daemon. It is more > > orthogonal too - if someone wants to store keys in xyzdb then they can > > make a subprocess to do that too. > > there's another catch: > > > One thing that would be good is having some sort of signing mechnanism > > > on the Agent. As I see you check to make sure the ownership of the > > > file is ok. > > > > > > How about another approach is to sign the Agent with the servers > > > private key (if that's possible??). > > Maybe may be included SHA hash of agent program in the config file > > and it may be checked before running the agent. But it is necessary? > > and who will check all the shared libraies used? > > > *** Brainstorming > > So, given that arguments, I'd like to offer a few ideas that might help. > > 1) How about loading some shared library (libraries) for retrieving > public keys? The library would provide interfaces like an > init(), uninit(), and lookup(). > Lookup would get the username and public key, and return a string > describing the login options ("environment=...") or NULL for no > public key found. > Alternatively it could provide a function for returning a list > of public keys, but I think doing a single lookup would be better. > > 2) If a separate process is the better way, how about skipping the > signature idea and instead provide the same level of securiy as > sshd itself? > Just open two pipes (STDIN, STDOUT) to an external program started > on sshd startup, use them for communication, and if the handles ever > get closed just log an error and don't use them anymore. > So if the external program gets changed on disk it wouldn't matter > (or at least, only as far as changing /usr/sbin/sshd would, too). > > 3) The other idea I heard (but more of a joke, I think) was to use > FUSE to provide the public keys from LDAP. > > > I'd like all interested parties to participate in this thread, to get a > discussion going, and get an approximate level of community interest. > > > Thank you for all answers. > > > Regards, > > Phil > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >
Philipp Marek wrote:> Hello everybody, > > I'd like to have LPK (or something like that - getting public keys from > LDAP) integrated into mainline OpenSSH. > > > *** First of all, a summary. > > The project page at > > http://code.google.com/p/openssh-lpk/ > > mentions that a few distributions include LPK per default; but reading the > various threads at > > Support for merging LPK and hpn-ssh into mainline openssh? > http://marc.info/?l=openssh-unix-dev&m=123483016220368&w=2 > > and > > Support for merging LPK into mainline openssh? > http://marc.info/?l=openssh-unix-dev&m=125655418812760&w=2 > > I get the impression that the most important argument is this one, citing > Damien Miller (http://marc.info/?l=openssh-unix-dev&m=125252189630862&w=2): >> Because the API presented by the LDAP libraries that I have looked at is >> quite ugly, because different platforms have different favourite LDAP >> APIs, because we don't want to build in support for every crazy variant >> schema that people will inevitably come up with.This argument doesn't hold much water any more; the Mozilla LDAP library has been abandoned. Novell has been shipping OpenLDAP's library for over a decade. The Mozilla project supports OpenLDAP's library. Sun was in the process of migrating off the Mozilla library and onto OpenLDAP (dunno how that has progressed since the Oracle acquisition). Even the FedoraDS/389DS guys are supporting OpenLDAP's library now. The API may still be ugly, but there's only one now, not several.> Regarding the other way, ie. using another process, (from the same mail) >> On Wed, 9 Sep 2009, Howard Chu wrote: >>> Hmm. Pushing this out to a separate process requires inventing yet >>> another IPC protocol, and adds one more moving piece that can break. >>> How does this approach avoid complexity? >> >> It avoids complexity in the critical part - the sshd daemon. It is more >> orthogonal too - if someone wants to store keys in xyzdb then they can >> make a subprocess to do that too. > > there's another catch: >>> One thing that would be good is having some sort of signing mechnanism >>> on the Agent. As I see you check to make sure the ownership of the >>> file is ok. >>> >>> How about another approach is to sign the Agent with the servers >>> private key (if that's possible??). >> Maybe may be included SHA hash of agent program in the config file >> and it may be checked before running the agent. But it is necessary? >> and who will check all the shared libraies used? > > > *** Brainstorming > > So, given that arguments, I'd like to offer a few ideas that might help. > > 1) How about loading some shared library (libraries) for retrieving > public keys? The library would provide interfaces like an > init(), uninit(), and lookup(). > Lookup would get the username and public key, and return a string > describing the login options ("environment=...") or NULL for no > public key found. > Alternatively it could provide a function for returning a list > of public keys, but I think doing a single lookup would be better. > > 2) If a separate process is the better way, how about skipping the > signature idea and instead provide the same level of securiy as > sshd itself? > Just open two pipes (STDIN, STDOUT) to an external program started > on sshd startup, use them for communication, and if the handles ever > get closed just log an error and don't use them anymore. > So if the external program gets changed on disk it wouldn't matter > (or at least, only as far as changing /usr/sbin/sshd would, too).On modern POSIX systems you can now reliably determine the uid/gid of the peer of a Unix Domain socket, so there's really no need to invent fancier solutions here.> 3) The other idea I heard (but more of a joke, I think) was to use > FUSE to provide the public keys from LDAP. > > > I'd like all interested parties to participate in this thread, to get a > discussion going, and get an approximate level of community interest. > > > Thank you for all answers.-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
----- "Philipp Marek" <philipp.marek at linbit.com> wrote:> Hello everybody, > > I'd like to have LPK (or something like that - getting public keys > from > LDAP) integrated into mainline OpenSSH. > > > *** First of all, a summary. > > The project page at > > http://code.google.com/p/openssh-lpk/ >There is an attempt of a successor at https://bugzilla.mindrot.org/show_bug.cgi?id=1668 It uses the same schema as tratitional lpk, the ldap-agent is run from sshd (once per authorization in this version). -- JFCh <jchadima at redhat.com>
----- "Damien Miller" <djm at mindrot.org> wrote:> On Wed, 9 Jun 2010, Dan Kaminsky wrote: > > > There's long history of using external commands as an extensibility > point > > (ProxyCommand for example) and, if there was going to be any way of > linking > > LDAP in, this would almost certainly be the best way. > > Yes, there is a patch in bugzilla that does exactly that. > Unfortunately, > I haven't had time to review it properly yet. >Damien, please review at least the sshd part of it. The sshd part is quite small and pushing it into mainstream makes possibility of further improvements. To maintain the patch across the changes of openssh sources fatigues me. Thx> -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev-- JFCh <jchadima at redhat.com>
Reasonably Related Threads
- Support for merging LPK into mainline openssh?
- [Bug 1663] New: Allow to use agent for distribution of public keys.
- Request for LPK patch to be merged
- Support for merging LPK and hpn-ssh into mainline openssh?
- Support for merging LPK and hpn-ssh into mainline openssh?