Bug 253719 - session handling in openssh destroy krb4 (afs) sessions
session handling in openssh destroy krb4 (afs) sessions
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openssh (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Tomas Mraz
Brian Brock
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-08-21 09:52 EDT by Klaus Ethgen
Modified: 2009-05-13 06:51 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-13 06:18:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Klaus Ethgen 2007-08-21 09:52:40 EDT
Description of problem:
We have the following setup for using AFS homes on RHEL.

   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

   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 
Comment 1 Tomas Mraz 2007-08-21 10:53:14 EDT
Can you please try

whether it fixes the problem?
Comment 2 Klaus Ethgen 2007-08-22 04:13:37 EDT
No, the problem still exists.
Comment 3 Tomas Mraz 2007-08-22 04:24:48 EDT
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.
Comment 4 Klaus Ethgen 2007-08-22 06:37:45 EDT
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 
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 

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.
Comment 5 Tomas Mraz 2007-08-22 06:42:17 EDT
(In reply to comment #4)
> Well, I find places in the ssh source where the sessions are destroyed.

You should also report the issue into upstream bugzilla (bugzilla.mindrot.org).
Comment 6 Klaus Ethgen 2007-08-22 07:24:45 EDT
No, there is no bug in the upstream.

If I disable ALL RedHat patches in the spec file sshd works well.
Comment 7 Tomas Mraz 2007-08-22 07:51:02 EDT
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?
Comment 8 Klaus Ethgen 2007-08-22 09:03:29 EDT
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.
Comment 9 Tomas Mraz 2007-08-22 09:31:05 EDT
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.
Comment 10 Klaus Ethgen 2007-08-22 09:40:49 EDT
No, it isn't, This was the first I tryed, commenting out the last 3 patches.
Comment 11 Klaus Ethgen 2007-08-22 11:38:18 EDT
OK, I identified the problem, it is the patch 26 openssh-4.2p1-pam-no-

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.

Comment 12 Tomas Mraz 2007-08-22 12:27:53 EDT
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);

Comment 13 Klaus Ethgen 2007-09-07 11:25:37 EDT
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.
Comment 14 Tomas Mraz 2007-09-07 14:44:53 EDT
There is no bug in the patch above. The bug is in the pam_afs code as I wrote above.
Comment 15 Klaus Ethgen 2009-05-13 05:56:11 EDT
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.
Comment 16 Klaus Ethgen 2009-05-13 06:51:18 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.