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