Cannot connect to host with SSH

Have you looked at the plist files in:

/Library/Preferences/SystemConfiguration

you could remove them and let Tiger create new ones.

Actually, this is exactly the problem I've just started having.

I found this post because by searching for the symptoms I've recently been experiencing. I installed 10.4.3 a couple days after it was released, and only this morning have I been unable to ssh from one computer to another. Much like the originator of this thread, this seemed to occur "all of a sudden," with nothing to my knowledge changing on either side.

This seems to only occur when directly connected network nodes are involved, for example, I cannot ssh from 172.16.1.1 to 172.16.1.2. If, however, my router at 192.168.2.1 is set up to port forward to 172.16.1.2, I can ssh from 172.16.1.1 to 192.168.2.1 successfully, thus bypassing the error.

What's odd, to me at least, is that in the broken scenario the ssh client is not sending a "Client: Key Exchange Init" immediately after the client and server protocols are established between 172.16.1.1 to 172.16.1.2.

Here's a crude example, from the point of view of the server, of it working...

172.16.1.1 -> 172.16.1.2 SYN
172.16.1.2 -> 172.16.1.1 SYN ACK
172.16.1.1 -> 172.16.1.2 ACK
172.16.1.2 -> 172.16.1.1 Server Protocol: SSH-1.99-OpenSSH_3.8.1p1
172.16.1.1 -> 172.16.1.2 Client Protocol: SSH-2.0-OpenSSH_3.8.1p1
172.16.1.2 -> 172.16.1.1 ACK
172.16.1.1 -> 172.16.1.2 Client: Key Exchange Init
172.16.1.2 -> 172.16.1.1 Server: Key Exchange Init
172.16.1.1 -> 172.16.1.2 Client: Diffie-Hellman GEX Request
172.16.1.2 -> 172.16.1.1 Server: Diffie-Hellman Key Exchange Reply
172.16.1.1 -> 172.16.1.2 Client: Diffie-Hellman GEX Init
172.16.1.2 -> 172.16.1.1 Server: Diffie-Hellman GEX Reply
...and so on...
And from there everything negotiates out and I'm connected.

Meanwhile, here's a broken connection

172.16.1.3 -> 172.16.1.2 SYN
172.16.1.2 -> 172.16.1.3 SYN ACK
172.16.1.3 -> 172.16.1.2 ACK
172.16.1.2 -> 172.16.1.3 Server Protocol: SSH-1.99-OpenSSH_3.8.1p1
172.16.1.3 -> 172.16.1.2 Client Protocol: SSH-2.0-OpenSSH_3.8.1p1
172.16.1.2 -> 172.16.1.3 ACK
172.16.1.2 -> 172.16.1.3 Server: Key Exchange Init
172.16.1.3 -> 172.16.1.2 ACK
... two minutes pass ...
172.16.1.2 -> 172.16.1.3 FIN ACK
172.16.1.3 -> 172.16.1.2 ACK
172.16.1.3 -> 172.16.1.2 Client: Key Exchange Init
172.16.1.2 -> 172.16.1.3 RST
172.16.1.3 -> 172.16.1.2 Client: Diffie-Hellman GEX Request
172.16.1.2 -> 172.16.1.3 RST

So what's up with the IP stack that's causing the client request to not get sent? Or is it the client that's broken? Did Apple unleash a time bomb with their last update, and mac-to-mac ssh is now slowly failing around the world?

The reasons I make that hypothesis are thus...
1) No mac on my network can ssh to any mac on my network, except via a router.
2) They all exhibit the same behavior of not sending the client key init until it's too late.
3) I can connect directly to either of my macs using any other ssh client on any other platform, including the same version of ssh client, SSH 2.0 (OpenSSH 3.8.1p1)
4) My ssh client can connect to other ssh servers.
5) No version of ssh client on mac alleviates the problem.

I'm looking over everything in /Library/Receipts to see when ssh and sshd were last updated, but I'm not hopeful that that's even part of the cause.

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

Actually, this just dawned on me as another weak hypothesis. Could the client, in an effort to really, really, really, really want to resolve the IP address be ignoring the server messages until it's too late?

Hi Don. Me too. (I usually hate "me too" posts, but this is tres weird)

I use ssh between my 5 macs (all at the same OS rev 10.4.3) frequently and noticed that it stopped working "all of a sudden". The only change in my entire environment is that I applied the recently released firmware update to an Airport Extreme and an Airport Express. Other than that, nothing has been installed on any of my machines.

I've been nosing around in the logs and noticed this entry logged when I rebooted, on the way down but prior to the next boot:

Jan 8 00:26:52 Mondo SystemStarter[429]: The following StartupItems failed to properly start:
Jan 8 00:26:52 Mondo SystemStarter[429]: /System/Library/StartupItems/AuthServer


I'm grasping at straws here.

Have you found anything new since you posted here?



PowerMac G5 Mac OS X (10.4.3)

New, not really. I can tell you that the AirPort Express Update doesn't have anything to do with it, since I haven't downloaded or applied it. I'm looking around for some help on this one, but it's really hard.

See, I've found some really infuriating posts that have been quite dilligent in pointing out the symptoms. So, in an effort to derail that kind of thing here, here's a list to all the well-meaning people who want to help, but might just end up pointing out the symptoms...

1) Yes, I see that my client really wants to reverse map the IP address I'm providing.
2) No, I do not have control over a local DNS
3) Yes, adding /etc/hosts entries mitigates the problem
4) No, I am not using Kerberos
5) Yes, I have tried all the pretty sshd options
6) No, I do not have this problem when using other clients
7) Yes, I can connect to other servers, as long as their IP addresses can be reverse mapped
8) No, I did not change my DNS settings
9) Yes, all my macs behave this way.

I understand that people want to help, and as a result I have found an incredible number of posts about this problem on the web, all of which tell people to add something to ssh_config, or sshd_config, or change an option, or change DNS, or change something to get it working again. Getting it working isn't the problem... finding out why it broke, inexplicably, to begin with is what I'd like to find an answer to.

The problem is this: On Mac OS 10.4.3, ssh no longer successfully works when connecting to a host via IP address when that IP address cannot be reverse mapped.

Having said all that, it's hard to find a way to provide good diagnostic data to people who might be able to help, since it's rare that any of us might have baselined our functioning ssh sessions. Hindsight is the truest, I suppose.

All I can provide is excruciating detail on what seems to be happening when it doesn't work. If anyone out there whose ssh client can connect to the IP address of a server can provide details on what happens when your ssh client works, it might go a long way in helping us.

I hope I don't upset too many people with the reiterative nature of this post, but here's all the data I've collected so far and my notes on the topic.

I installed 10.4.3 a couple days after it was released, and only this morning have I been unable to ssh from one computer to another. Yesterday, I was able to ssh from system to system, and even used sftp and scp to copy files. By the way, I truly do mean that. I used sftp to move a song file from one computer to another, logged out, put the mac to sleep. I woke up this morning, and decided to move another file - no go. I used up-arrow and enter to return to the previous night's working ssh commands without success.

This seems to only occur when directly connected network nodes are involved, for example, I cannot ssh from 172.16.1.1 to 172.16.1.2. If, however, my router at 192.168.2.1 is set up to port forward to 172.16.1.2, I can ssh from 172.16.1.1 to 192.168.2.1 successfully, thus bypassing the error.

What's odd, to me at least, is that in the broken scenario the ssh client is not sending a "Client: Key Exchange Init" immediately after the client and server protocols are established between 172.16.1.1 to 172.16.1.2.

Here's a crude example, from the point of view of the server, of it working...

172.16.1.1 -> 172.16.1.2 SYN
172.16.1.2 -> 172.16.1.1 SYN ACK
172.16.1.1 -> 172.16.1.2 ACK
172.16.1.2 -> 172.16.1.1 Server Protocol: SSH-1.99-OpenSSH_3.8.1p1
172.16.1.1 -> 172.16.1.2 Client Protocol: SSH-2.0-OpenSSH_3.8.1p1
172.16.1.2 -> 172.16.1.1 ACK
172.16.1.1 -> 172.16.1.2 Client: Key Exchange Init
172.16.1.2 -> 172.16.1.1 Server: Key Exchange Init
172.16.1.1 -> 172.16.1.2 Client: Diffie-Hellman GEX Request
172.16.1.2 -> 172.16.1.1 Server: Diffie-Hellman Key Exchange Reply
172.16.1.1 -> 172.16.1.2 Client: Diffie-Hellman GEX Init
172.16.1.2 -> 172.16.1.1 Server: Diffie-Hellman GEX Reply
...and so on...
And from there everything negotiates out and I'm connected.

Meanwhile, here's a broken connection

172.16.1.3 -> 172.16.1.2 SYN
172.16.1.2 -> 172.16.1.3 SYN ACK
172.16.1.3 -> 172.16.1.2 ACK
172.16.1.2 -> 172.16.1.3 Server Protocol: SSH-1.99-OpenSSH_3.8.1p1
172.16.1.3 -> 172.16.1.2 Client Protocol: SSH-2.0-OpenSSH_3.8.1p1
172.16.1.2 -> 172.16.1.3 ACK
172.16.1.2 -> 172.16.1.3 Server: Key Exchange Init
172.16.1.3 -> 172.16.1.2 ACK
... two minutes pass ...
172.16.1.2 -> 172.16.1.3 FIN ACK
172.16.1.3 -> 172.16.1.2 ACK
172.16.1.3 -> 172.16.1.2 Client: Key Exchange Init
172.16.1.2 -> 172.16.1.3 RST
172.16.1.3 -> 172.16.1.2 Client: Diffie-Hellman GEX Request
172.16.1.2 -> 172.16.1.3 RST

That's just a filtered view of the ssh problem... there's more to the problem.

host_1:~ user$ ssh -vvv 172.16.1.2
OpenSSH_3.8.1p1, OpenSSL 0.9.7i 14 Oct 2005
debug1: Reading configuration data /Users/user/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to 172.16.1.2 [172.16.1.2] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: fd 3 clearing O_NONBLOCK
debug1: Connection established.
debug1: identity file /Users/user/.ssh/rsa1 type 0
debug1: identity file /Users/user/.ssh/rsa2 type 1
debug3: Not a RSA1 key file /Users/user/.ssh/dsa2.
debug2: key type_fromname: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key type_fromname: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /Users/user/.ssh/dsa2 type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.8.1p1
debug1: match: OpenSSH_3.8.1p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1
debug3: Trying to reverse map address 172.16.1.2.
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
debug2: kex parsekexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex parsekexinit: ssh-rsa,ssh-dss
debug2: kex parsekexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijn dael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex parsekexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijn dael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex parsekexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac- md5-96
debug2: kex parsekexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac- md5-96
debug2: kex parsekexinit: none,zlib
debug2: kex parsekexinit: none,zlib
debug2: kex parsekexinit:
debug2: kex parsekexinit:
debug2: kex parsekexinit: first kexfollows 0
debug2: kex parsekexinit: reserved 0
debug2: kex parsekexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex parsekexinit: ssh-rsa,ssh-dss
debug2: kex parsekexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijn dael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex parsekexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijn dael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex parsekexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac- md5-96
debug2: kex parsekexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac- md5-96
debug2: kex parsekexinit: none,zlib
debug2: kex parsekexinit: none,zlib
debug2: kex parsekexinit:
debug2: kex parsekexinit:
debug2: kex parsekexinit: first kexfollows 0
debug2: kex parsekexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
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
Write failed: Broken pipe
host_1:~ user$

During the time that it's "trying to reverse map address", the system has sent out a DNS query regarding PTR record 172.16.1.2, one every 5 seconds, to the DNS servers configured on my system. No replies are ever received.

When I perform either "nslookup -type=PTR 172.16.1.2", I can observe the same results. Queries are sent, but no answers are received.

However, when I use "dig -t PTR 172.16.1.2", I, unsurprised, see this:

; <<>> DiG 9.2.2 <<>> -t PTR 172.16.1.2
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21026
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;172.16.1.2. IN PTR

;; Query time: 15 msec
;; SERVER: 172.16.73.10#53(172.16.73.10)
;; WHEN: Sat Jan 7 20:38:06 2006
;; MSG SIZE rcvd: 30

So there's no answer. Fine, but that's my diagnostic tool doing it, and apparently no longer how OS X resolves, or attempts to resolve, private IP space.

My question is this: What changed overnight to cause this behavior?<br>
PowerBook G4 Mac OS X (10.4.3) Killer Smile, Soul-Devouring Personality

I too will add an unfortunate "Me too" to this problem. I have Rendevous running on several linux machines, so when/if their IP addresses change, I can still access them via their hostname.local name.

The quick solution I've found to the problem is to hard-code the ip/name mappings right into /etc/hosts. Just add another line per host. When SSH goes to reverse-lookup, it will check there first, find it, and move on.

I also have tried all kinds of ways to disable reverse-lookups by SSH, and none of them seem to make any difference in its behaviour.

Because my setup involves dynamc ip addresses, the hard-coding isn't so much of an option for me. Names have been working just fine up until today.

Can you tell me what log file you found the reference to the AuthServer? I can't find anything about it on my system.

Sorry, this doesn't offer much help, but maybe my /etc/hosts quick-fix will get you a little further.

-Zach

dual 2GHz G5 - 10.4.3 Mac OS X (10.4)

I appreciate the tip. That one seems to abound. I do not mean this personally, but more as a rhetorical question:

What about those users, like me, who have been using their macs in a corporate testing environment where there is no reverse mapped DNS support for a 172.25.0.0 network?

That's only 64,000 /etc/hosts entries to make this less of a pain.

Of course, there's some 172.15.0.0, and some 172.35.0.0. And my home network is 172.16.0.0. Then there's the 10-net.

So that means I have to have ~16,000,000 entries for the 10.0.0.0 network, in case my job puts me on-site where a customer is using that, another ~16,000,000 entries to cover the 172.0.0.0 network, and ~64,000 entries to cover 192.168.0.0.

When it's all said and done, I'd have to have put over 30,000,000 entries in my /etc/hosts file just to clear up all the potential problems caused by a mystery bug. Yes, I can script that, but I will reiterate that I have no intention to create this massive workaround for something that should be working. As I have stated in another thread, I want to find the cause, and a fix, instead of working around the problem, because what am I to do when another bug creeps up that prevents my computer from operating in a manner I've come to expect. Let's say clicking on an application doesn't run it anymore, or the Open Firmware stops loading the OS.

Oh, and I called Apple today to report the issue and see if there's been a fix.

"Support for Terminal is minimal, but I'll try to help. Have you restarted the Remote Access service on the other computer?"

After we went through everything that's been detailed on these pages (which they can't/don't/won't read), they suggested that I reinstall my OS. Fortunately, I have another mac on which I can do that, but I have my doubts that it will work, as this issue has 1) sprung up on many Macs, asleep or not, and 2) happened on systems on which no changes were made.

Not to be an alarmist, but maybe this is the first worm/trojan/virus for the mac?

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

I'm seeing all over the message board that this problem started for a lot of people around September, 2005. Most of the posts also seem to be near the beginning of the month, like September 2, October 7, etc.

Something in the monthly script that's causing a slow-burn perhaps?

I'm looking into this now, and I'll post what I find. So this is not likely a virus or something like my previous post.

Here's something fun that I've noticed (note to self: look up definition of fun in the dictionary). The higher the system load, the less likely this problem is to occur.

I ran "uptime," and got this:

9:18 up 18:59, 6 users, load averages: 2.95 2.34 2.14

And while there's still a resolver delay, I can log in to systems that I was unable to log in to before. I looked at another user's Mac, whose system load is significantly lower (under 1.00), and they exhibit the error as described.

When my system load comes back down, I'll test again and post the results.

I certainly don't think raising the alarm of a virus or trojan is quite necessary. There just seems to be something funky with the resolver not handling local addresses correctly.

I understand your issue with a /8 network - nobody wants to be typing in all those host entries - nor should they. Similarly, my Rendevous setup is dynamic, and those IP's are going to change.

What about newly installed software? Anything - regardless how unrelated in the past few days?

Ahh yes - "Fun" You and I must have the same dictionary.

The higher the system load, the less likely this problem
is to occur.

So, I just need to have Photoshop cranking away on a 10mb raw file for me to SSH somewhere...

And I thought this would be hard to solve 😉

Seriously though, thats an interesting observation, I'd be interested to see if that's true with anybody else. I'll give it a try myself, since I'm usually running with not much load, I'm seeing the problem more often.

Nope. As stated, it was a concise, albeit confusing, 12-step program.

1) ssh to server
2) log out
3) sftp to server
4) copy music file
5) log out
6) rename music file
7) put mac to sleep
8) put self to sleep
... time passes ...
9) wake self
10) wake mac
11) up arrow twice to return to previous night's ssh command
12) boggle as previous night's functional command now fails.