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
