Working out a OS X 10.4 Tiger ssh implementation issue, slow logins

• Previous message: Tomasz Chmielewski: "Re: can't start remote X programs"
• Next in thread: Richard E. Silverman: "Re: Working out a OS X 10.4 Tiger ssh implementation issue, slow logins"
• Reply: Richard E. Silverman: "Re: Working out a OS X 10.4 Tiger ssh implementation issue, slow logins"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: 4 Jun 2005 18:43:12 -0700

This is making the rounds, and I would like to work it out and see what
potential solutions there are out there. I just updated to Max OS X
10.4:
ssh -V
OpenSSH_3.8.1p1, OpenSSL 0.9.7b 10 Apr 2003

There are scattered reports, and various solutions to an issue where
ssh logins take in excess of 30 seconds to instantiate a connection to
a remote host. There are various workarounds, but there is no
consensus.

What I know about the issue so far is that it is somewhat limited in
the scope to which is occurs. When it does occur, it seems to be in
routed environments.

In my case I use keys to login, but even without them, the problem
still takes upwards of 30 seconds to get to a password prompt.

ssh -vvv user@machine.host.com
Everything is pretty normal up to this debug line:

debug3: Trying to reverse map address ip.add.re.ss.

That's the point at which the stall happens, there also seems to be
some delay as well at this point:

debug1: Next authentication method: gssapi

My connection is me sitting on a comcast line, with a linksys router
in-between me and the internet. I am allowing comcast to send me DHCP
DNS servers.

If I change to my own recursive resolver, the problem does go away.
However, this was not needed in 10.2 or 10.3 OS X. So in some ways, it
does seem to be DNS related, but I am not sure just exactly where.

I am just barely able to consider myself an admin :-) so bear with me,
I start up a ssh connection and let tcpdump take a look at what it
going on. The entire ssh transaction made a total of 139 lines in
tcpdump, almost all of them being DNS requests. It is doing a lot of
really brain dead stuff like:
100.1.168.192.in-addr.arpa
There are tons of NXDOMAIN for many of the comcast NS's
I see:
ns5.attbi.com.domain: 15486+ PTR? 68.227.148.216.in-addr.arpa
And I have no idea why it looks that up, its not the inverse of the
remote host I am trying to get at.

Basically, the resolver is running through:
Ns[1-5].attbi.com.domain and that just takes time to talk to those all
five.

The amount of times it tries to reverse map my lan address
192.168.1.xxx is just weird as well.

I don't want to use my own recusrive resolver, as I use the comcast
line as a good way to test DNS propagation and such, not to mention,
with this such a hot topic on the Apple message boards, there needs to
be a solution, not everyone is running DNS of their own. My DNS is
pretty burdened with DNSBL lookups anyway.

Some people have found success with recompiling openSSH, others have
made entries into /etc/hosts, and some have had no success with either.

Nothing about my network has changed, just the OS, so I am wondering
what Apple did to ssh in Tiger, or is 3.8.1p1 just known problematic?

Could this at all be related to the ipv6 issues OS X has, and as far as
I know, still has, as a bug somewhere in the BSD kernel?

If building new fixes this, what exactly does that entail, is it just
one binary that could be put out for the benefit of others?

If there are any tests you need from me, I am happy to work on them, I
would love to get back to being able to ssh in while on the phone and
not have the customers wait 45 seconds for me to figrue something out.

-- 
Scott

• Previous message: Tomasz Chmielewski: "Re: can't start remote X programs"
• Next in thread: Richard E. Silverman: "Re: Working out a OS X 10.4 Tiger ssh implementation issue, slow logins"
• Reply: Richard E. Silverman: "Re: Working out a OS X 10.4 Tiger ssh implementation issue, slow logins"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]