When this sort of thing happens, I would suspect the volume on which the
user's directories are located.  If the bad users are all on a newer
disk/partition/nfs mounted device, it is possible that the mount
restrictions are different - and of course this may be across NFS (or
whatever you may be using).  It is unlikely that a PAM/Kerberos issue
affects only new users in the way described.

On one of my systems, regular users are mounted on /home/<n>, which is on
another container, while admin users are mounted on /home directly.  When
the regular user container fell over recently, I was most grateful that at
least I could login, su - and see what had happened!  Different scene but
same issue - some users can, some users can't.

Best wishes

John

John Logsdon                               "Try to make things as simple
Quantex Research Ltd, Manchester UK         as possible but not simpler"
[log in to unmask]              [log in to unmask]
+44(0)161 445 4951/G:+44(0)7717758675       www.quantex-research.com


On Mon, 22 May 2006, John Hanks wrote:

> Since I don't have effective control of my clients I modified your
> suggestion and removed authentication methods from the server. Removing
> public-key made it so that I now get a password prompt but it still
> times out after entering the password. Removing public-key and setting
> usePAM to no makes for password failure (even with a good password.)
> 
> I'm now focused on PAM or some connecting bit as the problem. I've
> enabled debug for pam_krb5 and comparing a successful login to a broken
> attempt, I don't see any difference in kerberos messages for the two. In
> fact, watching debug messages for su'ing ot a "good" user and a "bad"
> user doesn't show any differences other that the "bad" users always have
> a long wait for *something* to time out or happen.
> 
> Other things I've noticed:
> 
> [root@edna ssh]# useradd -d /tmp/testing testing
> 
> hangs.
> 
> Getent works perfectly fine for "bad" accounts.
> 
> [root@edna log]# getent passwd baduser
> baduser:ABCD!efgh12345$67890:10057:10000:Bad User:/home/baduser:/bin/bash
> 
> Thanks,
> 
> jbh
> 
> On Mon, 2006-05-22 at 17:45 -0500, teh wrote:
> > I wonder if this is the problem I had.  The symptoms sound vaguely familiar.
> > The fix is the following:  You have to limit the number of authentication
> > methods.  My solution is
> > 
> > PreferredAuthentications gssapi-with-mic,publickey,password
> > 
> > for the client config.  There is a limit on the attempts the sshd server 
> > will entertain before it closes down the connection.  I believe it's in 
> > the neighborhood of 4 or 5 attempts.  And, adding the kerberos auth seems 
> > to generate multiple attempts.
> > 
> > Try it.  I suspect it is the same problem.
> > 
> > Ken
> > 
> > 
> > 
> > On Mon, 22 May 2006, John Hanks wrote:
> > 
> > > Our setup (which has worked great until a few weeks ago) is:
> > >
> > >  * Windows Active Directory for LDAP and Kerberos
> > >  * Clusters using Scientific Linux 4.2
> > >  * Workstations using Fedora Core 4/5
> > >
> > > In the last couple of weeks we've seen some strange behavior. Some
> > > accounts (generally the older user accounts) are continuing to work
> > > fine. But newer accounts are no longer able to connect to any of the SL
> > > 4.2 clusters. At first I thought it was a kerberos issue, but I've been
> > > unable to find anything to point at a kerberos/LDAP problem. As far as I
> > > can tell, there is no significant difference between newer and older
> > > accounts within the LDAP directory.
> > >
> > > sshd hangs when attempting to exchange the public key. I've started sshd
> > > in debug mode with:
> > >
> > > [root@edna pam.d]# /usr/sbin/sshd -p 48000 -ddd
> > >
> > > then connected from a workstation using a "bad" account with this
> > > command:
> > >
> > > griznog@danaus ~ $ ssh -vvv -p 48000 markm@edna
> > >
> > > The sshd session logs these lines as the last bit of output before
> > > hanging:
> > >
> > > debug3: fd 4 is not O_NONBLOCK
> > > debug1: Server will not fork when running in debugging mode.
> > > debug3: send_rexec_state: entering fd = 7 config len 331
> > > debug3: ssh_msg_send: type 0
> > > debug3: send_rexec_state: done
> > > debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
> > >
> > > the ssh session connecting has this to say:
> > >
> > > debug1: Authentications that can continue:
> > > publickey,gssapi-with-mic,password
> > > debug2: we did not send a packet, disable method
> > > debug3: authmethod_lookup publickey
> > > debug3: remaining preferred: keyboard-interactive,password
> > > debug3: authmethod_is_enabled publickey
> > > debug1: Next authentication method: publickey
> > > debug1: Offering public key: /home/griznog/.ssh/id_rsa
> > > debug3: send_pubkey_test
> > > debug2: we sent a publickey packet, wait for reply
> > >
> > > To muddy the water some more, trying to 'su - baduser' behaves
> > > similarly, the su command hangs but it waits until something times out
> > > then succeeds. The problem doesn't exist on our FC5 workstations, either
> > > with su or ssh.
> > >
> > > If someone has any clues as to what might cause this or can provide some
> > > pointers to use while troubleshooting, I'd be grateful.
> > >
> > > Thanks,
> > >
> > > jbh
> > >
> > > John Hanks
> > > Utah State University
> > >
>