delay after ssh'ing into a server [SOLVED]

[Bill Tangren]

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.