I have been using sys-auth/pam_krb5-2.2.6 with a Heimdal 0.7 series KDC on x86 and amd64 for two months now with no problems. Please change the DEPEND to virtual/krb5 and keyword the package into ~arch instead of -*. This is the only pam_krb5 I've found that can correctly handle fetching openafs tokens (when used with a heimdal KDC), obviating pam-openafs-session for all cases except SSH with GSSAPI key-exchange but no OpenAFS ticket passing.
This is already fixed in 20030601 and 20030601-r1.
This is not a valid solution. pam_krb5-2003* and pam_krb5-2.2.6 are two entirely different packages - look at the SRC_URI in the ebuild and the DESCRIPTION. 2.2.6 comes from Fedora, whereas 2003* is from the SF.net pam_krb5 project. They share the same name, but 2.2.6 works properly with OpenAFS and OpenSSH where 2003* does not. The pam-2003* series also does strange things like depending on kth-krb if the "afs" USE flag is set. Please keyword this package.
I second that motion. I am using 2.2.6 on a production server and I am going through hell unmasking / keywording it correctly due to misversionning.
(In reply to comment #2) > They share the same name, but 2.2.6 works properly with OpenAFS and OpenSSH > where 2003* does not. The pam-2003* series also does strange things like > depending on kth-krb if the "afs" USE flag is set. Please keyword this > package. Yah, 2003* does indeed put a dependancy on kth-krb, but unfortunately claims that pam_krb5-2.2.6 work with everything out of the box are slightly exagerated. 2.2.6 attempts to validate allowed logins by reading the .k5login. This is cute and all, but it apparently attempts to do this before aquiring the AFS PAG even though the authentication succeeds. Unless all logins make $HOME system:anyuser readable, then pam_krb5-2.2.6 fails the login due to recieving a permission denied error when attempting to open ${HOME}/.k5login. Making ${HOME} paths system:anyuser globally readable in order to make pam_krb5-2.2.6 function is quite frankly "not a valid solution". Particuarly since AFS directory acl's are inherited from the parent directory. Every new directory created under ${HOME} would be created with system:anyuser read permission. The claim that pam_krb5-2003* does not work with OpenSSH is also exagerated. It works correctly so long as OpenSSH is capable of handing off the credential data correctly. This gets into a bit of a religious war that has been going on between OpenSSH and pam for quite a while. OpenSSH can't pass the credentials unless compiled with pthread support, but they have gone out of their way to make enabling pthread support difficult because people want to enable it thinking it improves performance, and for some reason OpenSSH isn't content to let people live with their own opinions and decisions. pam_krb5-2003* does not have this problem. Unfortunately, kth-krb is a dead project and not all of the pieces are in place to remove it from the systems yet. Such as this pam issue. The only problem with pam_krb5-2003* that I know of is the dependancy on the kth-krb package. The OpenAFS and OpenSSH claims are both ficticious, and misleading. Lastly, as noted, pam_krb5-2.2.6 does not work with OpenAFS unless one changes local security policies in order to allow it to read ${HOME}/.k5login on AFS, and there is no way to disable this check w/out disabling local account validation completely.
(In reply to comment #4) > 2.2.6 attempts to validate allowed logins by reading the .k5login. This is > cute and all, but it apparently attempts to do this before aquiring the AFS PAG > even though the authentication succeeds. Unless all logins make $HOME > system:anyuser readable, then pam_krb5-2.2.6 fails the login due to recieving a > permission denied error when attempting to open ${HOME}/.k5login. Making > ${HOME} paths system:anyuser globally readable in order to make pam_krb5-2.2.6 > function is quite frankly "not a valid solution". Particuarly since AFS > directory acl's are inherited from the parent directory. Every new directory > created under ${HOME} would be created with system:anyuser read permission. I retract this statement. It seems that the pam_krb5-2.2.6 requires the "token" argument in more sections then pam_krb5-2003* did. I now have pam_krb5-2.2.6 requesting tokens in the auth, password, and session events, as well as needing use_shmem=sshd in the auth and session events to get around openssh's inability to hand off credientials between these stages of authentication.
I have just been going through intense torture with the other two pam_krb5's and AFS with Heimdal, and after reading this bug I unmasked 2.2.6 and tried it, and it's been working perfectly in a production environment. This absolutely should go in ~arch.
(In reply to comment #5) > (In reply to comment #4) > > 2.2.6 attempts to validate allowed logins by reading the .k5login. This is I have seen this behaviour, too, but it seems to be due to stale krb5cc_* files left after an unclean logout (e.g. user logged out by system reboot). Otherwise, this module is working just fine on amd64. Please unmask this package.
*** Bug 146449 has been marked as a duplicate of this bug. ***
It still does not work: as75|21:06|1|>ssh shetach.chem.jyu.fi Password: Last login: Wed May 9 00:04:58 2007 from as75.adsl.tnnet.fi arno@shetach ~ $ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_45132) arno@shetach ~ $ kinit Password for arno@CC.JYU.FI: arno@shetach ~ $ klist Ticket cache: FILE:/tmp/krb5cc_45132 Default principal: arno@CC.JYU.FI Valid starting Expires Service principal 05/08/07 21:07:02 05/09/07 07:07:02 krbtgt/CC.JYU.FI@CC.JYU.FI renew until 05/08/07 21:07:02 arno@shetach ~ $
(In reply to comment #9) > It still does not work: There are many things that can prevent the OpenSSH/krb5 combo from working. What I currently use is pam_krb5-3.5 from eyrie.org (attached). Its only problem is that it provides no AFS support; when coupled with pam-afs-session, this isn't an issue.
Created attachment 118608 [details] pam_krb5-3.5.ebuild
Use 3.9; closing this.
