When making connections to other servers, I turned on the triple v option (-v -v -v) to see the debug output and I see it hang at this line for approx 60 seconds:
debug2: ssh_connect: needpriv 0
After that timeout, everything else proceeds normally.
Interestingly enough, if I just connect to localhost, that step flies right by, no delay...
Most of the time, ssh, because it's a very paranoid protocol, is slow because the target server does not resolve your IP to hostname. On the other server, place a host file entry with your current ip and hostname, see if it's any faster connecting.
After the updgrade to Leopard I too noticed that ssh was very slow in connecting to servers, taking 1 to 2 minutes. Apparently it has to do with the DNS (because there is no connection delay when specifying IP addresses directly) and some routers that do not handle DNS requests correctly.
I fixed the problem by specifying an alterntive DNS in the network preferences, instead of using the default one (which was indeed my router), and now ssh works fine as before.
10.4 had no problem and as near as I can tell, 10.5 and 10.4 are configured the same for ssh. (config file is the same anyway)
This leads me to believe that this is NOT an ssh issue but rather an issue with how ssh talks to the nameservers. If you specify nameservers for your connection in the network settings dialog, there is no delay. If you allow your dns servers to be automatically assigned via your network's DHCP server, there is a huge problem. All other services seem to work fine, just not ssh.
I see this on two networks. Both are using the dhcp server from a linksys box provided by vonage with their service.
Is there perhaps a bug/change in 10.5's dealing with dhcp?
Not sure about the DNS servers within the DHCP scope, I'm using pfsense at home on a laptop as a firewall for Surewest Fiber and I've never had a problem. I use dnsmasq as a dns cache and dhcp server as it automatically captures IP address assignments and creates the A and PTR records. I have all my dhcp mac clients using it as the first DNS server in the search order and the Surewest secondary as their secondary DNS server. I have had zero issues either using keyboard interactive and keys to log in to remote servers. I wonder if there is a way to get diagnostics turned on with more verbosity on your client and the target?
Now here's the interesting part:
The two nameservers that I am adding to /etc/resolve.conf are the VERY SAME nameservers that my router at 192.168.15.1 is set to use and assign for all dhcp clients. This suggests to me that there is a bug in how ssh handles dns lookups since the first /etc/resolve.conf should work (and does work fine in 10.4)
Since my last post I've been trying hard to find (again) the page where I got the DNS workaround, unfortunately without success.
According to what I remember, the problem lies in the router claiming to be a DNS, but not handling AAAA records correctly (whatever AAAA records are, I have no idea). Some software (and OSs) can deal with such DNS misbehavior without trouble, but others just hang for minutes.
BTW, the workaround I found was related to upgrading from 10.3 to 10.4, so, apparently, Tiger also suffered from this at some point. Funnily, last year I stumbled into the very same problem with a Linux distribution, and the workaround was exactly the same.
Turn off IPv6 stuff in the control panel.... Yup fast connections now.
It seems to be automatic support of IPv6 that is causing ssh to stumble over dns. It only happens on some networks. Can anyone figure out what the common denominator is?
Ok. I think I go it now. Can someone else test and confirm this.
It seems that ipv6 is working fine. The trouble comes with some linksys routers and their "DNS Proxy" feature. When that feature is on, 10.5 chokes on ssh connections. Turn it off (thus forcing dhcp to populate your /etc/resolve.conf with that network's nameservers rathen than the IP of the linksys device) and your are off and running.
Having just installed and run into the same problem with ssh I asked around and one guy said this...
"Assuming you are referring to problems when ssh-ing from a Leopard box
to other systems, then the problem is probably the new behavior of the
getaddrinfo() call in Leopard. Basically, that call in Leopard now uses
the RFC-recommended practice of first issuing a DNS SRV record request
rather than an A record request, and then falling back to the A record
request if the SRV request fails; unfortunately, apparently a lot of DNS
servers don't respond to the SRV request w/ an NXDOMAIN as they should,
and instead just drop the request, so getaddrinfo() retries the SRV
request a few times, and only after those requests time out does it try
to A request. So if ssh is using getaddrinfo() rather than
gethostbyname/getservbyname, then you it would hang like you describe
whenever you are pointing to a DNS server that doesn't respond well to
the SRV request. (There are also reports that Leopard may generate DNS
requests w/ an invalid RR type, which might explain why the servers
being queried aren't responding to them correctly.)
The easiest way to check if that's your problem would be to sniff
traffic on port 53 while trying an ssh connection, and seeing if your
box is making a SRV request or an A request. (If that is in fact your
problem, you may be SOL until a patch is released, as Googling, I don't
see any solutions other than hacking individual apps to use
gethostbyname() instead of getaddrinfo().)"
I did monitor port 53 and it is making SRV requests.
