SUMMARY: name resolution, but rather sshd problem

Hi list,

First I must give a big thanks to all responses. But my problem is not
resolved :-(  

Jeremy Rodriguez @cmsmechanical, Stephen Reppucci @logsoft, Chris Ricker
@gatech, Martin Schmitt @scsy and Bob Vickers @cs.rhul think my problem is
based on the reverse lookup (domain name service) made by the ssh server.

I tried to add the ssh client machine in /etc/hosts on the remote machine.
In addition I disabled "VerifyReverseMapping" in sshd_config

chupacabra @linuxlink
Has the same problem and waits for my summary. Please tell me whether my
described answers helps you? 

Steve Sandau @bath.tmac
Gives me the following hint: "On any of my machines, 'dig' always needs a
FQDN to work. Just a hostname will time out"

I think this is a task for a Red Hat consultant - we have support on these
machines (will keep you uptodate)

kind regards
Adrian

> Hi all,
> 
> We use Red Hat Advanced Server 2.1 (Pensacola) without any 
> errata or quartal updates. To administrate the servers 
> remotly we use the OpenSSH suite supplied by official RPMs 
> and did not change the default sshd_config.
> 
> A measurement with the shell keyword "time" shows me that 
> "ssh hostname" take 21 seconds till I can enter the password. 
> By adding the prefix domain.ch (ssh hostname.domain.ch) the 
> same not even take a half second.
> 
> The stub resolver (resolv.conf) ist properly configurated 
> with valid named servers and "search domain.ch" plus "domain 
> domain.ch". In /etc/hosts there is a correct entry below 
> localhost with IP address and hostname.domain.ch. The 
> nsswitch.conf (and host.conf) points "hosts" to files then 
> dns. The error is definitely not our named configuration, 
> because with SUN and Windows servers it works fine.
> 
> The really freaky is: the output of "nslookup hostname", 
> "traceroute i37390" and "ping hostname" appears immediately. 
> The answer given by "dig hostname" is "connection timed out; 
> no servers could be reached" although a trace show me that he 
> take the right named server.
> 
> Because i think the problem is the ssh client, here a debug:
> # ssh -v -v hostname
> OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug1: Rhosts Authentication disabled, originating port will 
> not be trusted.
> debug1: restore_uid
> debug1: ssh_connect: getuid 0 geteuid 0 anon 1
> [waiting, waiting]
> debug1: Connecting to hostname [192.168.x.x] port 22.
> 
> The IP settings on eth0 are correct 
> (/etc/sysconfig/network-scripts/ifcfg-eth0).
> 
> Hope anyone can help me. Any suggestions are welcome.
> 
> best regards
> Adrian Meier
>  
> UNIX systems administrator
> T-Systems Switzerland _______________________________________________
> LinuxManagers mailing list - http://www.linuxmanagers.org
> submissions: LinuxManagers-35TzE1X9F6582KRnZfj+bdi2O/[email protected]
> subscribe/unsubscribe: 
> http://www.linuxmanagers.org/mailman/listinfo/> linuxmanagers
_______________________________________________
LinuxManagers mailing list - http://www.linuxmanagers.org
submissions: LinuxManagers-35TzE1X9F6582KRnZfj+bdi2O/[email protected]
subscribe/unsubscribe: http://www.linuxmanagers.org/mailman/listinfo/linuxmanagers