Description of problem: We have the following setup for using AFS homes on RHEL. pam.d/system-auth: ... auth required pam_env.so auth sufficient pam_unix.so likeauth auth sufficient pam_afs.so use_first_pass ignore_root set_token auth required pam_deny.so ... ssh/sshd_config: ... UsePAM yes PasswordAuthentication yes ChallengeResponseAuthentication no ... While this setup work fine on RHEL4 with ssh version 3.9p1-8.RHEL4.1 this setup is broken on RHEL5 with ssh version 4.3p2-16.el5. More detailed the AFS authentication do well with both systems but the user has no PAG and no AFS ticket on EL5 so no access to his $HOME. The reason is that AFS do the token and PAG setup in the auth phase but ssh seams to destroy both directly after. This is not only a non working problem than also a problem of the security as the PAG is unset. Have a special note that we have to use AFS with KRB4 and not with KRB5 as our university do not have a KRB5 setup for AFS. A forward port of openssh 3.9 from old EL4 fix the problem and everything works well.
Can you please try http://people.redhat.com/tmraz/testing/openssh-4.3p2-24.el5.src.rpm whether it fixes the problem?
No, the problem still exists.
Then I'm afraid that pam_afs is doing something wrong. Does it support the session phase? (pam_open_session, pam_close_session) If yes, can you add 'session optional pam_afs.so' to the /etc/pam.d/sshd and test whether that helps? I'm not really sure what's destroying the PAG and AFS ticket.
Well, I find places in the ssh source where the sessions are destroyed. However, afs has only support for auth section. The pam_open_session is only a dummy implementation. (pam_close_session is implemented for destroying tokens.) The problem is that the session setup for afs has to be done in the auth part for any reason. (I did not check this in source but I find some notes about that.) If ssh means that it should intersept the pam process this is an error. If it has to clean some environment this has to be done in front of pam not between.
(In reply to comment #4) > Well, I find places in the ssh source where the sessions are destroyed. Concretely? You should also report the issue into upstream bugzilla (bugzilla.mindrot.org).
No, there is no bug in the upstream. If I disable ALL RedHat patches in the spec file sshd works well.
Could you find which concrete patch breaks it? Also you wrote above that there are places where the sessions are destroyed, can you be more concrete? Also which pam_afs do you use? From openafs?
Hmm.. Difficult as there are many patches. 'll see. About the places I identified, I just saw them(it) when starting examing the source. But I do not remember where. And yes. pam_afs from openafs.
I'd suppose it could be the openssh-4.3p2-pam-session.patch but I'm still curious how is that possible that the tickets are removed.
No, it isn't, This was the first I tryed, commenting out the last 3 patches.
OK, I identified the problem, it is the patch 26 openssh-4.2p1-pam-no- stack.patch. The problem is that this patch not only replace the pam_stack with include than also put one new session module, pam_keyinit.so with the revoke option, into the stack.
I see that openafs initializes the session keyring on its own. Perhaps that's the reason why it breaks. Well then you can simply workaround the problem by removing the pam_keyinit.so from the config. Note that the revoke option doesn't actually affect this because it is effective on session close only. Maybe the removing the 'force' option could help. But for the real fix I think that pam_afs should be fixed to properly reinitialize creds when asked by ssh. Removing the following code from src/pam/afs_setcred.c should do it. } else if (flags & PAM_REINITIALIZE_CRED) { if (logmask && LOG_MASK(LOG_DEBUG)) pam_afs_syslog(LOG_DEBUG, PAMAFS_REINITCRED, user); RET(PAM_SUCCESS); }
I don't see, what the unclear point is. I did find the bug in the patch above and that there is too much in it.
There is no bug in the patch above. The bug is in the pam_afs code as I wrote above.
Just as there is a workaround for a redhat bug this doesn't mean that there is no bug in it. Redhat is known to dislike third party software but there is no alternative in redhat to use for accessing afs. The fact is that afs (openafs) works for ages and the behaviour is not uncommon and also supported by the pam strategie. It *is* a bug that redhat made a patch to not stay compatible with upstream off openssh or with the pam provided funktionality. So please remove or fix that buggy patch.
I do not know why you close the bug as notabug without further comment. I think, that ist very outrageous! However, you seems to be not inclined to fix bugs so I set the right state (wontfix). Just stay with a buggy enterprise solution. I will just stay with working around the bug.