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
>