Bug 72597

Summary:	Login via ssh extremely slow
Product:	[Retired] Red Hat Linux	Reporter:	Michal Jaegermann <michal>
Component:	openssh	Assignee:	Nalin Dahyabhai <nalin>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	8.0	CC:	barryn, john
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-07-14 23:12:03 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.