Cannot connect to host with SSH

Recently the hard drive on my powerbook g4 began crashing. Luckily I was able to backup the user folders to another machine before replacing the drive. Once the drive was replaced, I installed Tiger. Once the powerbook was back up and running, I moved the user folders back from the other machine.

Now, I am unable to make a connection to my web site host via SSH. Here is a copy / paste from the terminal window of a recent attempt:

shell:~ user$ ssh -v -l user host
OpenSSH_3.8.1p1, OpenSSL 0.9.7g 11 Apr 2005
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to host [209.59.154.44] port 22.
debug1: Connection established.
debug1: identity file /Users/user/.ssh/identity type -1
debug1: identity file /Users/user/.ssh/id_rsa type -1
debug1: identity file /Users/user/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
A parameter was malformed
Validation error

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
A parameter was malformed
Validation error

debug1: SSH2 MSGKEXINIT sent
debug1: SSH2 MSGKEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2 MSG_KEX_DH_GEXREQUEST(1024<1024<8192) sent
debug1: expecting SSH2 MSG_KEX_DH_GEXGROUP
debug1: SSH2 MSG_KEX_DH_GEXINIT sent
debug1: expecting SSH2 MSG_KEX_DH_GEXREPLY
debug1: Host 'host' is known and matches the RSA host key.
debug1: Found key in /Users/user/.ssh/known_hosts:1
debug1: ssh rsaverify: signature correct
debug1: SSH2 MSGNEWKEYS sent
debug1: expecting SSH2 MSGNEWKEYS
debug1: SSH2 MSGNEWKEYS received
debug1: SSH2 MSG_SERVICEREQUEST sent
debug1: SSH2 MSG_SERVICEACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
Connection closed by 209.59.154.44

I have determined that this is a problem somewhere between my powerbook and using Airport to connect wirelessly to the internet. I have a Base Station connected to a cable modem. To test this theory, I connected the powerbook directly to the cable modem via ethernet and had no problem using SSH.

Here are some additional troubleshooting steps I have taken trying to get this to work:
Deleting the known hosts file.
Deleting the .shh folder.
Adjusting Airport configuration settings.
Triple checking the firewall is off.
Repairing permissions using Hard disk utility.
Attempting to use SSH in a new user account.

I have also done the following to make sure it is my powerbook having the problem and not the host:
Successfully connecting to host from a different Mac running Tiger.
Successfully connecting to host from a PC running Linux.
Successfully connecting to host from a PC running Windows XP.

Can anyone help me?
Jona

Posted on Oct 30, 2005 8:49 AM

32 replies

Jan 9, 2006 11:03 AM in response to Zach Chadwick

Well, it's not load related, and the problem seems to be clearing up on my end, albeit not consistently.

At least the problem's resolution seems to be consistent with its inception. I'll keep everyone posted.

Jan 9, 2006 2:13 PM in response to Don Flinspach

Thanks Don,

Please keep us updated. For now, I've hard-coded IP's in my /etc/hosts file until a solution is found.

Jan 9, 2006 3:57 PM in response to Zach Chadwick

Well, things are no longer broken here at the office.

Just to confirm, everyone here who was experiencing the problem changed nothing to account for the failure, and did nothing to remedy the problem to account for their individual repairs. Fortunately, I still have tcpdumps and -vvv output of things going wrong, so I'm going to keep looking at that historical data and maybe realize what happened.

Also, I did The Unthinkable and imported the full 10, 172, 192.168, and 168.254 networks into my /etc/hosts file. The Resulting Slowness was truly both a terrible and comical thing to behold. So remember: The Unthinkable + /etc/hosts = The Resulting Slowness.

So I've excised all workarounds, which in my case was just to add a few hosts to NetInfo, and I'm getting no connection failures anymore. While there is still an issue of slowness, because of ssh attempting to reverse map the host address, failure to connect, as mysteriously as it had begun, is now ending.

But when will it rise again?

This reminds me of a Penny Arcade comic... Maybe people weren't buying enough Mac Macs over Christmas, and because of that, the Mac, who is very sick, having had a spell cast on him by The Evil Wizard, had changed into The Netreaper and was flying from computer to computer, collecting packets.

So remember, kids, to always buy more Mac Macs, even if it means stealing from your parents.

PowerBook G4 Mac OS X (10.4.3) Killer Smile, Soul-Devouring Personality

Jan 9, 2006 5:34 PM in response to Don Flinspach

And now, even the slowness is gone. For me, this is trouble gone, but problem unsolved.

Is anyone else seeing an eventual recovery of service? For some of you, I understand this might mean undoing some DNS or /etc/hosts or NetInfo changes, but a little feedback goes a long way here.

Jan 9, 2006 5:42 PM in response to Don Flinspach

Let me undo my /etc/hosts stuff and get back to you on that... I know that its possible the lookups that had come from Netinfo (etc) might be cached by the resolver. Have you rebooted after removing all the hacks and seen what happens?

Update:

Seems better now - even with the static entries removed, however I can't take my own advice and reboot until later. I'll check back tomorrow with you.

Jan 9, 2006 6:51 PM in response to Don Flinspach

Yep, it's now working here too. Very, very strange.

I didn't change a thing. Nothing.

Is it possible that some oddities were occurring far upstream in DNS-land?

I happen to have a terminal window open that had some activities from when it wasn't and then was working. Specifically, reverse lookup of "private" IP addresses.

From when ssh wasn't working:

[Mondo:~] brooks% host 172.16.77.18
;; connection timed out; no servers could be reached

Now, when ssh is working:

[Mondo:~] brooks% host 172.16.77.18
Host 18.77.16.172.in-addr.arpa not found: 3(NXDOMAIN)

Hmmm.

Jan 9, 2006 10:09 PM in response to Brooks Graham

I'd like to think that might have been it, except for the fact that when this started I was testing against upstream DNS and getting no errors. DNS was functioning fine, but my Mac wasn't. Perhaps it's something esoteric that I was missing.

However, a friend I asked to check something today was having odd Bluetooth errors that he couldn't figure out, swore he didn't change anything, couldn't figure out why it happened, and weren't fixed on a restart (sound familiar?), so he just re-paired the devices. I'd bet good money that it would have been resolved had he just waited. I'd liked to have seen that. Also, one of my Macs couldn't find some files in the Finder, but that problem seems to have cleared as well, without a restart.

Whatever it is, it's going to be very hard to convince Apple to check on something that's hard to pin down like this, although one would think that automated testing would have found this. And if they're not doing real-world testing, like with vanishing DNS and malformed responses, on a system that really wants to be integrated to the Internet but is capable of acting without it, then they need to really reconsider their test plan.

I say we chalk it up to The Mac, and we all need to buy more Mac Macs.

Jan 19, 2006 8:41 PM in response to Don Flinspach

This ssh problem started for me right after installing 10.4.4 incremental update. Now I can't ssh to my web host. ssh on non-updated mac still works.

Is there a way to downgrade only ssh?

Jan 25, 2006 4:27 AM in response to gillywonk

Sure, there’s a way, but unless I miss my guess this problem doesn’t have anything to do specifically with ssh. It does seem to have a lot to do with how OS X resolves names and IP addresses, which isn’t easy to downgrade at all.

Jan 25, 2006 4:51 AM in response to Don Flinspach

I do not have any ssh problems at all. At all macosx version everything worked fine. (10.3 - 10.4.4) The ssh works on both internal (192.168.0.0) en external hosts. On all of my macs (2 Powermac G4's, 2 iMacs, 1 iBook G4).
I don't understand why you are having problems... Maybe it is the network setup, your router? Dynamic settings?
I don't know, but everything works fine over here.

Did anyone of you try to install a newer ssh version? That can be done very simple with a package manager like fink. When something in the unix side doesn't work properly, installing new versions of things might help...

Jan 26, 2006 1:46 AM in response to John Keates

As snide as this might sound, you might want to review the entirety of this thread before posting that you have no problems at all. This thread was attempting to determine why those of us who were attempting to use ssh to connect to hosts within a private IP network were having problems.

It seemed that while nobody posting here had done anything that would indicate why the problems began, nor had some of us done anything to correct the inexplicable issue, but instead simply explored the problem for cause and hopeful correction, the problem using ssh to connect to private IP space appeared for all of us (and others not posting) without cause, existed for a period of time, and disappeared at or around the same time.

"Installing new versions of things might help..." isn't really helpful to someone who's attempting to understand the nature of what's broken. Also, allow me to rhetorically inquire why, when nothing was done that would explain why software began malfunctioning, changing versions and upgrading software might be the immediate solution? If your car inexplicably stopped running, would you go out and buy another car?

Having just commited the gross indecency of what might be considered flaming, allow me to invite you to contribute to our continuing exploration and investigation of the problem that was recently being discussed in this thread. I would really love to hear about other's experiences when their ssh mysteriously stops allowing connections within private IP space so that a real fix can be found instead of cobbling together little hacks and workarounds.

PowerBook G4 Mac OS X (10.4.4) Killer Smile, Soul-Devouring Personality

Jan 26, 2006 5:14 AM in response to Don Flinspach

Being in on the original thread, I'll chime in again here. I think Don said it right. Flame potential or not.

From a technical point of view, Brooks Graham I believe was on the right track:

From when ssh wasn't working:

[Mondo:~] brooks% host 172.16.77.18
;; connection timed out; no servers could be reached

Now, when ssh is working:

[Mondo:~] brooks% host 172.16.77.18
Host 18.77.16.172.in-addr.arpa not found: 3(NXDOMAIN)

Getting the NXDOMAIN returned by DNS for a private address space is correct, and I believe has something to do with a funky DNS server somewhere out there.

I would suggest trying out that 'host' command when you're having problems and see if you get the same results. Since so many different people with different configs all had the same problem at the same time without actually changing anything, placing the blame on an upstream DNS server seems to be the most logical answer.

It may be that in your corner of the world, the DNS servers are having trouble again.

Good luck.

Jan 26, 2006 6:18 AM in response to Don Flinspach

Well, yeah sorry about that post...

Feb 3, 2006 5:44 PM in response to John Keates

Ok, I've read the entire thread and I'm still stumped. I've been using COTvnc to control Macs remotely. I use ssh to do rebooting and cleanup. Our set up at the remote site is:

(1) headless Mac mini - FileMaker file host (OS 10.4.4)
(1) iMac G5 (10.3.9)
(1) iMac slot loading (10.3.9)
(1) iMac Rev B (10.3.9)

All the Macs run FileMaker and are set up for remote login. I'm running DynDns and an updater on the headless mini. We are on a WiFi system through an ethernet bridge and "router" with port 22 forwarded to the headless mini.

Up until the last of January, I could ssh into the Mac mini or vnc into it. I used the mini to ssh or vnc into the remaining units. Now, I can't get into the mini remotely - using the dns name or the actual IP address. I get connection refused.

Ok - Tiger on the headless mini! I switched the port forwarding to the other Macs, one at a time and tried to ssh in. Connection refused!

I'm completely puzzled as to the cause of this.

Doug

Feb 15, 2006 1:03 AM in response to Doug Duffield

That sounds completely like what we were already discussing. Sudden, inexplicable, first-of-the-month failure. My guess is that it’s cleared up by now with no action on your part, or that you’ve taken the DNS (or /etc/hosts) steps to work around something that shouldn’t be breaking.

In the words of Alice: “Curiouser and curiouser.”

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Cannot connect to host with SSH