Fix slow SSH connections (delays) on Mac OS X

SSH connections on Mac OS X are sometimes very slow (long delays) although it's instantaneous on Linux. Modifying an option in the configuration files fixes this injustice.

Update Client Configuration

sudo vi /etc/ssh_config

Replace this line:

# GSSAPIKeyExchange yes

by:

GSSAPIKeyExchange no

Don't forget to remove the sharp!

Update Server Configuration

sudo vi /etc/sshd_config

Replace this line:

#UseDNS yes

by:

UseDNS no

Again, don't forget to remove the sharp. That's it !

Note

May be you're not enthusiastic about hacking your SSH configuration files. Another solution is to add the IP addresses you're going to connect to (or which are going to connect to your mac) in /etc/hosts.

 

Feedback

are there any security implications, or is this just pure speed man
Ivanoats
Oct 5, 2007
#1
Yikes, that's much faster. I use ssh frequently for application deployment, maintenance, and git SCM, so this will really speed up my workflow.
topfunky
Oct 6, 2007
#2
I don't think it creates any security issues, but I'm not a network guru. Actually, it should be like that by default:

GSSAPIKeyExchange
Specifies whether key exchange based on GSSAPI is allowed. GSSAPI key exchange doesn’t rely on ssh keys to verify host identity. The default is ‘‘no’’. Note that this option applies to protocol version 2 only.


Reference:
http://www.opensourcemanuals.org/manual/sshd_config/synopsis
Maestric
Oct 6, 2007
#3
This addresses the symptoms but not the underlying problems. If turning off DNS works, you're reverse DNS is broken. The GSSAPI stuff is a good thing long term, which is why it was enabled by default -- make sure the sshd on the servers your connecting to is up to date. If these are beyond your control, these config changes will help, but know what you're giving up.
Age
Oct 8, 2007
#4
Age, you seem to have a good idea of what is this "GSSAPI stuff" and how it works. Could you please give us more details about "good thing long term" and what we're "giving up"?
Maestric
Oct 9, 2007
#5
I had a problem where SSH connections would be really slow after passing login credentials. Eventually (sometimes after as much as 10+ minutes) I would be connected. I also noticed that X11 was loading all the time, and I couldn't see what app would be causing it. Eventually I figured out the fix to both. /etc/ssh_config had the line "ForwardX11 yes". I changed it to "ForwardX11 no" and both problems went away. Apparently X11 auth was hanging when I'd ssh to some hosts.
Munkey
Nov 28, 2007
#6
This solution worked great for me! Thank you! I only had to change the server's sshd_config file. I am sshing from a linux box.
John
Mar 7, 2008
#7
Worked! Thanks !
Jari
Jan 30, 2009
#8
Yes this is helpful.
ravi
Oct 23, 2009
#9
The DNS trick solved it for me, thanks!
João Moreno
Mar 30, 2010
#10
Works for me. Thanks a bunch.
Dat Nguyen
Jun 15, 2010
#11
test
test
Jan 29, 2011
#12
I noticed a big change in login speed using ssh when I 'upgraded' to the Lion seed package. Setting
GSSAPIKeyExchange no
did the trick. No need to update the server settings.

Thanks for posting.
Martin Hawkins
Mar 6, 2011
#13
I had the same problem when I upgraded to Lion today. Had been working fine until then. The solution was to open the network preferences and set the DNS name servers to those provided by the ISP. I had been using the router as the dns resolver but Lion seems to have some problems with that.

It required no changes to sshd_config and you're better off leaving the defaults alone unless you specifically require a non-standard setting. By disabling DNS is a security risk.
Bruce
Aug 25, 2011
#14
I didn't want to change the system default config file in /etc/ssh_config so I added a config file to my user's ssh config:

~/.ssh/config

That file reads:

Host *
GSSAPIAuthentication no
GSSAPIKeyExchange no

This fixed the delay for me (on Lion)
Scott
Oct 20, 2011
#15
I did what Scott did, and it worked perfectly (running 10.7.2).
A
Oct 23, 2011
#16
yep, Scott's method is ok on 10.7.0
NV
Jan 14, 2012
#17
Anyone know how to fix this in Lion?

%> host cm-11
cm-11.foo.com has address 192.168.199.71
%> ssh cm-11
ssh: Could not resolve hostname cm-11: nodename nor servname provided, or not known

host, dig, and nslookup all work, but ssh, ping, ftp etc fail name lookups.

Bruce
Jan 26, 2012
#18
"UseDNS no" rocks! I always connect from a virtualbox with winxp to my mac lion, I changed the parameter UseDNS to "no" and everything starts to work great! svn, winscp and all connections that go throw ssh!

Thank you very much!
juands
Mar 13, 2012
#19
Scott's method is perfect! Thanks!
iin
Mar 19, 2012
#20
After migration to a new Lion (10.7.4) macbook pro I was getting 10 second delays on ssh connections to many hosts. In my case it was due to ssh trying to do ipv6 negotiation, which apparently fails after a timeout. The cure was to set the following value in /etc/ssh_config:

AddressFamily inet

(You can set it in ~/.ssh/config as well.)
robert
Jun 2, 2012
#21
*that* is what fixed my 10 second problem. Thank you sir.
Geezer!1337
Jun 25, 2012
#22
GSSAPIKeyExchange uses the GSSAPI library to do kerberos authentication of hosts instead of using ssh host keys. It avoids all the known_hosts bother, but requires that you setup either kerberos or active directory and then get the linux boxes that you are trying to ssh into joined to the kerberos real / active directory domain.

That is typically more of a PITA than most IT admins are willing to go through so nearly everywhere you can turn off the GSSAPI-related options in your ssh_config and it'll be fine. The only way that you might want this is if your work actually has the servers that you are ssh'ing to joined to a domain and setup properly to do key exchange. And its relatively new enough that even at the two kerberos infrastructures that I've maintained I didn't have servers that supported it, so I couldn't get rid of ssh host key management.

Anyway, ask your IT guys at work about it, and in the 99% case when they do dog-tilt-head and look at you like you're speaking a foreign language to them, you can safely turn this off with precisely zero impact to security. If you happen to work someplace that does decent IT and has very strong kerberos and security knowledge (say, Morgan Stanley) then you would not want to do this.

You'd also know because your mac laptop would need to be joined to a domain/realm or you would need to auth to the domain to get a TGT in order to authenticate the hosts.

If there's any question ssh to a host at work and then in another window run this:

% klist
klist: krb5_cc_get_principal: No credentials cache file found

or

% klist
bash: klist: command not found

means you probably aren't using kerberos for ssh logins or you'd see the host tickets in the output of that command.

and there's also little security risk from 'UseDNS no' as well. dns is lousy security and often not maintained well, and the crypto in ssh does not rely on it. you're better off paying attention to the host-key-mismatch error messages (and those are such a mess typically that everyone tends to ignore those anyway -- which is why gssapikeyexchange would be slick -- but sysadmins continue to think that kerberos is too hard to deploy....)
Lamont
Jul 11, 2012
#23
I'm having an ssh problem also. I just did a firebreak with Season Pass on my ATV2, and I started to install nitoTV by going in to my MAC Terminal and entering the ssh root@10.0.1.2 info. I was asked for a password and entered in our normal MAC password instead of "ALPINE". I think I entered the wrong password so many times that it's locked me out or something. I even tried resetting a new password with "sudo passwd root", giving a new password and then tried again. For some reason it still didn't recognize the new password.
So, my current problem is.... I am no longer getting prompted to enter a password after I enter "ssh root@10.0.1.2". I think I've figured out that the proper password should be "Alpine", but I after typing "ssh root@10.0.1.2". I get the same message... "ssh: Could not resolve hostname root: nodename nor servname provided, or not known"
JHand77
Jan 1, 2013
#24
Hey mate, thanks for the tip. I was trying to run sqlyog on vmware and connect via a ssh tunnel. Authenticating was slow and sqlyog would time out (I couldn't see an option to adjust the timeout value for sqlyog - and searching turned up little). So after doing this, it authenticated alot faster and I was in!
Nathan Wallis
Jan 28, 2013
#25