delay after ssh'ing into a server [SOLVED]
Bill Tangren
bjt at aa.usno.navy.mil
Fri Oct 6 20:44:05 UTC 2006
Stephen Carville wrote:
> Bill Tangren wrote:
>> Stephen Carville wrote:
>>> Bill Tangren wrote:
>>>> Stephen Carville wrote:
>>>>> Bill Tangren wrote:
>>>>>> Mahesh Pokala wrote:
>>>>>>> Check /etc/resolv.conf for valid dns entries
>>>>>>> Check /etc/nsswitch.conf for valid entries.
>>>>>>>
>>>>>>
>>>>>> I don't see anything unusual in them, and I haven't changed them.
>>>>>> Also, they are the same as the same files on the other servers,
>>>>>> and those servers don't have this problem. I've tried this from
>>>>>> several different servers. I've also asked others to try, and they
>>>>>> have the same problem.
>>>>>
>>>>> try ssh -vv user at wherever to see where the hang is happening.
>>>>
>>>> [root at eunomia ~]# ssh -vv bjt at aa
>>>> OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
>>>> debug1: Reading configuration data /etc/ssh/ssh_config
>>>> debug1: Applying options for *
>>>> debug2: ssh_connect: needpriv 0
>>>> debug1: Connecting to aa [10.1.5.93] port 22.
>>>> debug1: Connection established.
>>>> debug1: permanently_set_uid: 0/0
>>>> debug1: identity file /root/.ssh/identity type -1
>>>> debug1: identity file /root/.ssh/id_rsa type -1
>>>> debug1: identity file /root/.ssh/id_dsa type -1
>>>>
>>>> Then the 30 second pause... then
>>>
>>> Still looks like name resolution problem. Just for S&G try putting
>>> yoru machine and IP address in /etc/hosts and make sure yout host
>>> line in nsswitch.conf includes files. AKA:
>>>
>>> hosts: files dns
>>>
>>
>> I already had "hosts: files dns" in /etc/nsswitch.conf, and I added
>>
>> 10.1.5.154 eunomia.usno.navy.mil eunomia
>>
>> to /etc/hosts. I then restarted network just to make sure the hosts
>> file was reread. No change. There is still a 30 second delay.
>>
>
> I'm about out of ideas. Do you have access to the server? If so you
> can run increase the LogLevel temporarily to DEBUG3 (lots of stuff
> dumped to logs so don't leave it that way). Or you can shut down the
> regular sshd and start one of Debug mode (-D). From your domain name I
> suspect the above might be out of the question :-)
>
> For details see
> man sshd
> man sshd_config
>
I run (and have for some years) ssh from xinetd, so that I can limit access to
the service via the only_from directive. I've never had any problems. Well,
earlier this week, I added USERID to the defaults directives in /etc/xinetd.conf:
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID USERID
log_on_failure = HOST USERID
cps = 25 30
}
It was the USERID on the log_on_success line that was causing the problem. I
don't know why, but removing it, and restarting xinetd service did the trick.
Thank you all for your help.
More information about the redhat-list
mailing list