ssh won't connect to hostname


OSX 10.1
FreeBSD 4.3 and 4.4

From the OSX box I was able to ssh to the FreeBSD boxen. I did some stuff unrelated to ssh (moved a web dir), logged out, and then later tried to log back in. All I get is this:

[osx:~] user% ssh -v -v -v jon@www
OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /etc/ssh_config
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 501 geteuid 501 anon 1
debug1: Trying again...
debug1: Trying again...
debug1: Trying again...
Secure connection to www refused.

However, if I use the IP address instead of the hostname, it works fine. It appears to be a client-side issue since Nifty Telnet SSH running in Classic mode still gets through just fine. The host name resolves. Further, another FreeBSD box just started having the same problem with my osx box after working all day. ?? It's like osx is caching info (the key?) about the server side, but said key is corrupted or changed some how. I've tried recreating my .ssh directory and my keys with no luck.

any help appreciated
The output from ssh -v which reads,

Secure connection to www refused.

suggests the remote side is not running sshd at all. Since you were able to connect previously, but not later, and you say the hostname resolves, one possibility which comes to mind is multiple IPs for www. If you try

telnet www 22

several times, does each one always give something like,

Connected to www.
Escape character is '^]'.

or do you ever receive

telnet: Unable to connect to remote host: Connection refused

If you do see the Connection refused there's probably multiple IP addresses for the www name.

If that's not it, I'm confused.
This is a problem with OS X. I have had the same problem with several servers, but it only happens when the server has multiple ip addresses (load balencing hardware), or when the ip has multiple hostnames. I belive its because ssh on OS X is checking the ip of the host you type in by reverse dns'ing it, and it finds multiple entrys so it bombs out and says it can't connect.

Im not sure If this is the problem, but it happens to me reliably if the above conditions are present, but if they are not, then it connects fine. Very annoying.
No, the hostname has only one IP. The machine itself has dozens of IPs and hundreds of names. I can use "uncorrupted" names without issue, and IPs seem to be working thus far.

The telnet to port 22 works just fine. Doing some more digging... it would appear the lookup is failing from within ssh. I can ping the hostname just fine, so name res is working fine on the osx box globally. However, when I try to "ssh www" while having tcpdump running, I see an ANY lookup for the host name, and a response from the DNS server (running on the same server box in this case), but then nothing else.

Thoroughly confused.
I ran tcpdump on the osx box.

- 'ping www': looks up the hostname and pings the right IP address

- 'ssh www': ZERO network activity as reported by tcpdump; ssh reports connection refused

- 'ssh': connects up just fine

I'm quite confused. Sure looks like ssh is broken, but I don't want to point fingers too early here.
My OSX box was set to use a DNS cache that I was testing. The IP for dnscache (from the djbdns package) did not have reverse/forward info. I discovered this by trying to run nslookup. When you run nslookup, it attempts to find the name of the server it's using, before it actually does any lookups. Well that was failing so nslookup was failing. Got me thinking. Turns out ssh is using nslookup-type routines when looking up the host name. First it tries to lookup the name of the dns server it's using, if that succeeds it moves on to resolving the host and then attempts the connection. Weird, don't really see the good in that. Further, it would be nice if the error message reflected that failure instead of "connection refused."

I first changed /etc/resolv.conf directly. Nslookup then worked fine, but ssh still failed. Fired up tcpdump, and lo and behold ssh was still querying the broken server. I had to go change it in the Network Control Panel for ssh to recognize the change.

2 things I can't explain: 1) the "broken" host names were working when I first brought up the 10.1 box. 2) Lots of other host names worked fine the whole time. IMHO, something's broken (or badly misconfigured at compile time) in OSX's ssh.