Slow password authentication

[Terrence]

I have an rp7420 that has a distinct pause after we type in the password. It's running 11.23 in a service guard cluster. The other node in the cluster doesn't have this behavior. There's no delay at all during any other part of the connection/login process.

The server itself is rarely all that busy and averages 7% CPU and disk utilization.

The delay isn't bad but it's the first time I've seen this and I don't want it to worsen.

Has anyone seen this before?

[Court Campbell]

Is this with every logon attempt? Also how are you logging in, e.g., ssh, console, telnet. It could be dns. I have seen pauses in logins while the service does a reverse dns lookup.

[Terrence]

The delay is everytime and happens with both telnet and ssh. Also it happens only during password authentication not during connection so DNS doesn't enter into it.

It also happens when I su. The other server in the cluster is identical and it doesn't have the problem.

[Sandman!]

What do you use for password authentication? Is it local or vendor/third party software like DCE?

[Terrence]

Local authentication, nothing fancy or unusual.

[Steven E. Protter]

Shalom,

Yes, I saw it today while I was resurrecting two old D class boxes in my apartment.

The problem was because the /etc/hosts file did not contain a record for the machine I was logging in to.

For some reason login response is nasty slow on HP-UX systems when nsswitch.conf checks files first and the secondary DNS server is slow or Microsoft(or both).

Making sure there is a valid /etc/hosts entry for exactly how your user log in will probably help.

Lets say the host ip is 192.168.0.10


/etc/hosts


192.168.0.10 galactica galactica.your.net


You will notice I covered the shortname and the fdqn or fully qualified domain name.

Also check /etc/resolv.conf

If those servers can not be contacted or are slow it will make login seem interminable.

Slow response on the hostname lookups of the client machines can also contribute to this problem.

SEP

[Terrence]

The hosts file is identical to it's twin in the SG cluster which does not have the pause. All entries in the hosts file are accurate. Also this event happens during the password authentication only so there is no DNS activity as part of this action.

The DNS entries are correct and resolv.conf is also configured correctly.

[A. Clay Stephenson]

Are you running NIS, LDAP, or local passwords? Are the user's home directories local or NFS mounted? Try killing the pwgrd daemon and see if the behavior changes. You don't even need to restart it.