SLES 11.2 slow SSH password prompt

Linux and Unix-Like SuSE
1

We are having an issue with slow password prompts via SSH login on all of our SLES 11.2 boxes. The output from a ssh -v login attempt shows a delay here:

debug1: SSH2_MSG_SERVICE_ACCEPT received

This issue only happens on the first logon of the day; subsequent logons are normal. Adding the client's workstation hostname/IP to /etc/hosts, and setting "UseDNS no" in /etc/ssh/sshd_config has no effect. Both the client and server can resolve respective hostnames and IP's via nslookup and dig as well.

The peculiar side is that we also have a few SLES 10.4 boxes without this issue. Between these two versions, all of the applicable config files are identical. The only server-side difference we can see thus far is the version of OpenSSH, which is minor:

SLES 11.2 = OpenSSH_5.1p1, OpenSSL 0.9.8j-fips 07 Jan 2009
SLES 10.4 = OpenSSH_5.1p1, OpenSSL 0.9.8a 11 Oct 2005

Update 11/29/12: We performed a trace during the delay and our network team found something interesting. During the first logon of the day, there is a massive ldap query performed against the AD forest, as if a cache has expired and needs refreshed. This could explain why the delay only happens once a day. We are looking into the samba/winbind configs to see if there is a setting that controls when the cache expires. Perhaps the "winbind cache time" parm could be of value to us since these servers don't have routine ldap activity.

Suggestions?

2

Hello, do you have other kind of authentication enabled?

As GSSAPI for example? We got a problem of slow password prompt due to the GSSAPI being enabled.
Once disabled, as we don't need it, the prompt is fast as should be.

Cheers.

3

Thanks for your reply. I forgot to specifically mention that I've ruled out GSSAPI out as a factor, via the workaround I mentioned in the post.

4

Seen this happen with Debian-based OSes a lot. It's usually an issue with the /etc/nsswitch.conf file.

5

When comparing the applicable entries between a working machine and the one having issues, we don't see a difference between their /etc/nsswitch.conf files. Both have:

hosts: files dns

Also, this issue only happens on the first logon of the day, all subsequent logons are normal until a long period of time passes.

6

Anything show up in the logs during these initial logins? Its /var/log/secure on Red Hat. Might be different on SuSE.

7

The equivalent on SLES is /var/log/messages which shows the login info for the session, however there are no significant delay's noted in the time stamps.

8

A shot in the dark:
does

nslookup host

take a long time?
Perhaps it helps to trace your sshd:

strace `pgrep -P 1 -u 0 -x sshd`

Note down the function where it pauses.
If you have a quiet system, use strace -f to follow the child processes.

9

Thanks everyone for your suggestions, we finally discovered the issue.

We took a login trace using tcpdump, which revealed RPC sessions between Samba/winbind and the DC, well along in a conversation, were being terminated overnight. The login delay was being caused with Samba/winbind trying to reestablish the connection, which eventually times out.

I presented this to our network team who then placed an override on the firewall, the issue was resolved for us the next day.