Red Hat Bugzilla – Bug 72597
Login via ssh extremely slow
Last modified: 2007-04-18 12:46:00 EDT
Description of Problem: This problem is NOT exhibited on RH 7.3 and earlier installations. When logging from another machine on a local network I am getting 'password:' prompt really immediately. Only after a password is provided a machine goes away and quite succesfuly for a long while pretends to be crashed. Eventually a shell prompt shows up and everything seems to be normal from this point on. Local machines are all in /etc/hosts everywhere and /etc/nsswitch.conf has 'passwd: files nisplus' (it was not modified from a default). Other network services which could be reasonably expected to do DNS checks, say amd asked on a test machine to mount file systems exported by others, do not show any symptoms of that sort. Running 'ssh -v' does not reveal anything beyond that after password is typed there is a loooong wait.
I tried SSHing from a Slackware 8.1 box to my laptop running (null), but I failed to reproduce the problem.
Any suggestions how to look for what happens? The first time I was already quite convinced that something crashed.
Forgot to add. The test machine is configured with a static name and address on a "private" subnetwork and is not using DHCP. In various times there is usually between two and six machines on thins network, configured in an analogous way, and they do not exhibit this behaviour. Indeed the same hardware, but booted with my "normal" setup instead of a test one, is not doing anything like described above.
It could be somehow attempting to do a reverse lookup and taking a long time to fail. I've seen that with other server programs on other Unix-like operating systems (including other Linux distributions). You might want to see what appears in the logs in /var/log/* after the big delay (I'm not sure which exact log files you should look at, maybe /var/log/messages or /var/log/secure -- in any case, use tail -f).
> It could be somehow attempting to do a reverse lookup and taking a long > time to fail. Yes, quite likely. And indeed in in /var/log/secure I can find "Could not reverse map address 192.168.23.2" But in such case this is a bug as /etc/nsswitch.conf says: hosts: files nisplus dns and there is an entry for 192.168.23.2 in /etc/hosts. As I noted in the original report other services which can reasonably expect to perform reverse lookups do not seem to suffer from that problem.
In my experience, only the first ssh is slow. If you logout and log back in, or if you open a second ssh, it is not slow. It may be similar to whatever it is that causes KDE to initially be so painfully slow after it has been idle for a long time.
Michal, are you still seeing this problem on Fedora Core or Red Hat Enterprise Linux? If so, you should update the product and version on this bug. If not, then you should close this bug as WONTFIX, since Red Hat Linux 8.0 and 9 have reached end-of-life.