When trying to build net-misc/openssh-6.2_p1 with USE=ldap set, pkg_setup() fails with #v+ >>> Starting pkg_setup * Sorry, but this version does not yet support features * that you requested: ldap * Please mask openssh-6.2_p1 for now and check back later: * # echo '=net-misc/openssh-6.2_p1' >> /etc/portage/package.mask !!! ERROR in net-misc/openssh-6.2_p1::gentoo: !!! In pkg_setup at line 4693 !!! booooo !!! Call stack: !!! * pkg_setup (/var/tmp/paludis/net-misc-openssh-6.2_p1/temp/loadsaveenv:4693) !!! * ebuild_f_setup (/usr/libexec/paludis/0/pkg_setup.bash:43) !!! * ebuild_main (/usr/libexec/paludis/ebuild.bash:668) !!! * main (/usr/libexec/paludis/ebuild.bash:691) diefunc: making ebuild PID 31750 exit with error die trap: exiting with error. I consider this a bug, since it breaks builds, especially, since there is a well-known mechanism for disabling certain USE-flags by package. I would appreciate if somebody put this into use.mask, disabling it the proper way and not breaking package builds. Reproducible: Always Steps to Reproduce: 1. echo 'USE="${USE} ldap"' >> /etc/make.conf 2. emerge net-misc/openssh 3. echo $?
(In reply to Andreas Wiese from comment #0) yeah, no. the error message told you how to resolve it locally.
Its also worth noting that the OpenSSH guys integrated AuthorizedKeyCommand support into this release. While I'm personally a fan of LPK support, the OpenSSH developers were not and LPK support had no chance of landing in there. You can effectively achieve LPK support with AuthorizedKeyCommand yourself by writing a small script that does the LDAP query on your behalf.
(In reply to Doug Goldstein from comment #2) hmm, is this something we can automate in the upgrade scenario ? like read the current sshd_config, generate an appropriate query command, and then set it to use that ? or otherwise make it a bit easier ? if it's a pita, then so be it. we can drop the patch and change the pkg_setup logic to instead look at the sshd_config for LPK options and die if we find those enabled. that'll make the user manually do the upgrade, cut over to the new option, and then move on.
I've re-added support for ldap in 6.2_p2-r1 with an updated lpk patch, please test.
Infra(myself) will undertake to test the new LPK patch within a week or two. I'm doing a big upgrade at work this weekend, then moving house next month, so it'll happen, just not quickly.
(In reply to Doug Goldstein from comment #2) > You can effectively achieve LPK support with AuthorizedKeyCommand > yourself by writing a small script that does the LDAP query on your behalf. shell script with openldap http://git.fs.lmu.de/gaf-etc-portage.git/blob/HEAD:/bin/authorized_key_command.sh python script with syslog http://git.fs.lmu.de/gaf-etc-portage.git/blob/HEAD:/bin/authorized_key_command radhermit provied a second version of the lpk path, that worked on my setup. (the first segfaulted).
(In reply to SpanKY from comment #3) > (In reply to Doug Goldstein from comment #2) > > hmm, is this something we can automate in the upgrade scenario ? like read > the current sshd_config, generate an appropriate query command, and then set > it to use that ? or otherwise make it a bit easier ? > We definitely can if we're comfortable making a shell script that calls out to ldapsearch and sed. xmw posted a good example in comment #6, but that unfortunately relies on your /etc/ldap.conf being populated and having the same credentials that you use for your sshd_config Not sure how we want to proceed now that the LPK patch is updated. I've personally started switching systems to the new setup only because it will work on distros that don't apply LPK to openssh so I don't have to roll my own pkg constantly. I still use the LPK schema for OpenLDAP.
(In reply to Doug Goldstein from comment #7) we can at least start detecting & warning today, and pointing people at the example scripts here. hopefully that'll start migrating some users which means we'll have a smaller userbase in the future who gets forced over vs voluntarily migrating.
(In reply to Doug Goldstein from comment #7) > [/etc/ldap.conf] ... having the same credentials ... In fact it's /etc/openldap/ldap.conf and symlink it to /etc/ldap.conf didn't work. __BUT__ You can give any parameter on the command line, can specify the AuthorizedKeyCommandUser to root or whatever and keep it all in the script - as done so in the python version. As you can do within the sshd_config. You can setup any dummy credential and allow access to just sshPublicKeys, (In fact, we allow all machines that can reach the ldap server to search browse uid and sshPubliKey, just to let nss_ldap work w/o credentials, and users login and update their password by successfully binding as their entity. No extra-credential needed. Sadly passwd can't be configured to use user-bind to write passwords, so pam_password_prohibit_message redirects to the WebUI - which needs no extra cred, either besides network "location") (In reply to Doug Goldstein from comment #7) > I still use the LPK schema for OpenLDAP. Ack, I think the AuthorizedKeysCommand is at least an equal replacement for UseLPK, and you can have mixed setups, no need to care what other distros do.
/etc/openldap/ldap.conf and /etc/ldap.conf are NOT the same file. They have a slight overlap in syntax, but they are different files. Does SSH allow the AuthorizedKeyCommand to read the sshd_config? If yes, then we can read any LPK arguments from there, plus /etc/ldap.conf, just like the base LPK. I would prefer whatever script to use those arguments directly, as so to break as few configurations as possible. If no, then we're limited to /etc/ldap.conf, and hopefully it won't bork when somebody uses the undocumented configuration options like LpkPubKeyAttr, LpkUIDAttribute. It's probably worthwhile looking at the nss_ldap/pam_ldap code as well, to borrow the timeout logic for a misbehaving LDAP server, and handle multiple keys.
- No response from user in long time - USE=ldap obsoleted by AuthorizedKeysCommand
