Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

A script to workaround slow ssh connection issues UNIX
A lot of people have complained about ssh being slow when connecting to others hosts when you give a hostname instead of an IP address. The problem is obviously related to DNS name resolution. At my workplace, this might also have to do with the fact that we are using the .local domain for our network (which was decided long before Apple used it for Rendezvous).

However, I did not want to care where the problem really comes from, so I wrote a script that works around ssh's slow name resolution. It resolves the hostname using the host(1) utility, and calls ssh using the resulting IP address. Even after extensive web searching, I did not find out why ssh is only slow for some people (depending on various network and ssh config settings), so I do not really know whom this hint applies to. But it still might be worth a try if you think your ssh is slow when connecting, and you've already checked your DNS and ssh settings.

Put the following script into some directory in your PATH, for instance /usr/local/bin, name it ssh, make it executable by running chmod +x /usr/local/bin/ssh, and there you go.
#!/bin/zsh
destuser="${1%@*}"
desthost="${1/*@}"
shift
ip=${$(host "$desthost")[4]}
if [ "$destuser" = "$desthost" ]
then
       dest="$ip"
else
       dest="$destuser"@"$ip"
fi
exec /usr/bin/ssh "$dest" "$@"
There is a little bug I did not care to fix: The script assumes that your first argument will always be hostname or user@hostname. Any ssh options or commands must be given afterwards.
    •    
  • Currently 1.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (2 votes cast)
 
[14,115 views]  

A script to workaround slow ssh connection issues | 10 comments | Create New Account
Click here to return to the 'A script to workaround slow ssh connection issues' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Find the real problem instead
Authored by: britrock on Dec 28, '07 09:45:16AM

If you are having slow ssh connections it makes a LOT more sense to track down the actual problem instead. The solution posted is just a band aid.

To debug an ssh connection simply add the '-v' option. For instance, if the command you would normally run is 'ssh foo@bar.com' then change it to 'ssh -v foo@bar.com'.

You will get a great deal of debug printed on the screen, and most of it won't make sense, but by look at the last bit that is printed before the delay you'll get a good idea what the cause of the problem is. At that point you'll want to read through the man pages for sshd_config, and for ssh_config and hopefully you'll be able to find a setting to fix the problem.



[ Reply to This | # ]
Find the real problem instead
Authored by: cran on Jan 06, '08 07:40:07AM
If you are having slow ssh connections it makes a LOT more sense to track down the actual problem instead. The solution posted is just a band aid.
You are right, it is better to find and fix the problem. But sometimes it just saves a lot of time to work around instead of fixing. I tried to make this clear by putting the word "workaround" in the title instead of "fix".

[ Reply to This | # ]
A script to workaround slow ssh connection issues
Authored by: weatherbug on Dec 28, '07 10:07:51AM

If this is a host you are ssh'ing to often, you could always put an entry in /etc/hosts as well. That would eliminate the DNS lookups entirely since the resolver library goes to the hosts file BEFORE attempting to do a DNS lookup.



[ Reply to This | # ]
A script to workaround slow ssh connection issues
Authored by: cran on Jan 06, '08 07:30:25AM

/etc/hosts certainly helps in some cases. For me it does not because we use dynamic IP addresses and dynamically changing DNS entries via DHCP in our network.



[ Reply to This | # ]
A script to workaround slow ssh connection issues
Authored by: linuxdude on Dec 28, '07 10:23:31AM

I've experienced a similar problem on Linux systems. I believe that some versions of ssh by default try to resolve a hostnames using IPv6 first, then IPv4. The fix was to use the ssh -4 option. To make that happen every time, create an alias for ssh and define it to be "ssh -4".



[ Reply to This | # ]
A script to workaround slow ssh connection issues
Authored by: pumpichank on Dec 28, '07 10:41:11AM

I had this problem after upgrading from Tiger to Leopard and it drove me crazy. Successive levels of ssh -d didn't really help narrow the problem down, and I even tried running a debug on the server just in case.

In any event, I was debugging a different problem (new wireless router) and I noticed that I had an old domain in my static DNS search list. This domain was for an old job, and the domain no longer exists. I removed this and just search my dhcp provided domain, and ssh is once again very fast -- as fast as from my Linux boxes.

Go to Network Preferences -> Advanced -> DNS and make sure you only have the search domains you're expecting.



[ Reply to This | # ]
A script to workaround slow ssh connection issues
Authored by: Iceberg on Dec 28, '07 11:03:46AM
Like many, I've had the same issue for a long time. After much digging and network sniffing, I found out that the ssh client on Mac OS X (Tiger and up, at least) performs a DNS lookup for the SRV record of the host you are connecting to.

SRV records essentially specify the port on which a service runs, and are seldom used.

For example, when I was connecting to a host named "server1.domain.local", an SRV record lookup was made for the following domain name:

_ssh._tcp.server1.domain.local

Since there was no such SRV record, there was a slight delay before the client (presumably) fell back to another method. So I simply added the following record in the local DNS server's appropriate zone file:

_ssh._tcp.server1 IN SRV 0 100 22 server1

And voilĂ ! No more delays.

Granted, not everyone runs a local DNS server, but this should help some of you.

[ Reply to This | # ]

A script to workaround slow ssh connection issues
Authored by: sweth on Dec 29, '07 05:57:10AM
You shouldn't be seeing the SRV behaviour in Tiger, just Leopard. For those who care about the details, here's the explanation I sent to someone on a local sysadmin mailing list when they were running into ssh delays right after Leopard was released:

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. (I've heard 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.) So if ssh is using getaddrinfo() rather than gethostbyname/getservbyname, then it would hang like you describe whenever you are pointing to a DNS server that doesn't respond well to the SRV request.

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.

(The DNS-SRV RFC explicitly notes that services whose protocol spec doesn't explicitly discuss using SRV should NOT use SRV, but I believe that LDAP is one of the few services that does discuss using it (and SRV was, I think, originally created by Microsoft folks to support LDAP stuff), so someone apparently compiled ssh in Leopard to use getaddrinfo for the LDAP auth lookup--and apparently was too lazy to put in logic to ONLY use getaddrinfo for an LDAP auth host lookup, and not for non-LDAP auth lookups and/or the actual ssh host lookup.)

AFAIK the only fix is to recompile SSH or to pre-empt the SRV lookup as this hint describes.



[ Reply to This | # ]
A script to workaround slow ssh connection issues
Authored by: cran on Jan 06, '08 07:35:15AM

Thanks for pointing this out. It seems like a resonable explanation.

Now the harder part is to convince our DNS admins to put this record into the DNS configuration for hundreds of servers.



[ Reply to This | # ]
A script to workaround slow ssh connection issues
Authored by: datasmid on Dec 29, '07 08:49:54AM
Long delays in ssh to anything that ends with .local because Mac OS X then first does a multicast DNS request (part of Bonjour) and after that a unicast SRV request to the DNS server.

Company runs a MS Active Directory domains ending in something like country.company.local.
.local domain is very tied to Bonjour which is hard to disable.

After some investigation we are now able to skip the multicast DNS
request using /etc/resolver/local.1 and start with a unicast query (see
http://docs.info.apple.com/article.html?artnum=107800 and execute the
suggested script) but still delays

the MS server doesn't answer on SRV, so OSX DNS waits for a timeout. The server should send back an NXDOMAIN error. (please forward to MS DNS wiz...)


[ Reply to This | # ]