Re: delay after ssh'ing into a server [SOLVED]



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@wherever to see where the hang is happening.

[root@eunomia ~]# ssh -vv bjt@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.



--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list



Relevant Pages

  • Re: delay after sshing into a server
    ... Also, they are the same as the same files on the other servers, and those servers don't have this problem. ... debug1: Connecting to aa port 22. ... I then restarted network just to make sure the hosts file was reread. ... There is still a 30 second delay. ...
    (RedHat)
  • Re: delay after sshing into a server
    ... those servers don't have this problem. ... try ssh -vv user@wherever to see where the hang is happening. ... debug1: Connecting to aa port 22. ... I then restarted network just to make sure the hosts file ...
    (RedHat)
  • Re: delay after sshing into a server
    ... Also, they are the same as the same files on the other servers, and those servers don't have this problem. ... debug1: Connecting to aa port 22. ... I then restarted network just to make sure the hosts file was reread. ... Or you can shut down the regular sshd and start one of Debug mode. ...
    (RedHat)
  • Re: delay after sshing into a server
    ... Also, they are the same as the same files on the other servers, and those servers don't have this problem. ... debug1: Connecting to aa port 22. ... there is a 30 second delay before I get the password prompt. ...
    (RedHat)
  • Re: The libntp resumee...
    ... you have too much faith in ntp. ... IF he is using his own servers (not outside ... using seven DIFFERENT poll intervals, one for each server because seven ... Currently we observe that both entry hosts can both become restricted due to ...
    (comp.protocols.time.ntp)