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
> >