Bug 72597 - Login via ssh extremely slow
Summary: Login via ssh extremely slow
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: openssh
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-08-25 22:35 UTC by Michal Jaegermann
Modified: 2007-04-18 16:46 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-07-14 23:12:03 UTC
Embargoed:


Attachments (Terms of Use)

Description Michal Jaegermann 2002-08-25 22:35:28 UTC
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 08:53:13 UTC
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 15:56:59 UTC
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 16:04:26 UTC
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 20:54:25 UTC
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 21:16:15 UTC
> 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-22 00:19:40 UTC
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 14:05:40 UTC
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.