Bug 72597 - Login via ssh extremely slow
Login via ssh extremely slow
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: openssh (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-25 18:35 EDT by Michal Jaegermann
Modified: 2007-04-18 12:46 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-07-14 19:12:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2002-08-25 18:35:28 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.
Comment 1 Barry K. Nathan 2002-08-27 04:53:13 EDT
I tried SSHing from a Slackware 8.1 box to my laptop running (null), but I
failed to reproduce the problem.
Comment 2 Michal Jaegermann 2002-08-27 11:56:59 EDT
Any suggestions how to look for what happens?  The first time I was already
quite convinced that something crashed.
Comment 3 Michal Jaegermann 2002-08-27 12:04:26 EDT
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.
Comment 4 Barry K. Nathan 2002-08-27 16:54:25 EDT
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).
Comment 5 Michal Jaegermann 2002-08-27 17:16:15 EDT
> 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.
Comment 6 John Klingler 2003-10-21 20:19:40 EDT
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.
Comment 7 Barry K. Nathan 2004-07-14 10:05:40 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.