Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Running ssh user@hostname takes ~30s. Here's the scenario:

  • this is a VM on the local LAN
  • Windows and Mac machines get instant login
  • am using Debian and I could reproduce with an Ubuntu machine
  • someone using Ubuntu says that logging into my machine (local LAN) is also instant
  • using hostname IP address takes about half as much time (~15s)


Using ssh -vvv user@hostname, here's where it waits the most:

debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic

And then it waits a bit here:

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
share|improve this question
do you use password or pubkey authentication? and if password, is the a id_dsa or id_rsa file in your ~/.ssh? maybe your ssh installation tries the wrong authentication first and your server doesn't deny but simply ignore that request resulting in that 30s timeout –  Tobias Kienzler Jan 10 '11 at 14:11
@tobias I use password and I don't have "~/.ssh" file. That's a directory, and it only has "known_hosts" file in it. –  Tshepang Jan 10 '11 at 16:59
It looks like you have a 15s DNS timeout. Maybe the server is doing a DNS lookup; if you can, make sure you have UseDNS no in sshd_config on the server. In any case, run ssh -vvv user@hostname to see where the login is hanging. –  Gilles Jan 10 '11 at 19:52
@gil Thanks. I updated the question. I'll ask the admin to check for that UseDNS setting. –  Tshepang Jan 10 '11 at 20:07
@Tshepang: Oh, you're using Kerberos (GSSAPI) authentication. I'm not familiar with it. If it's misconfigured, maybe it's causing the delay. This is something you can ask your admin. DNS might be a red herring; it's the most common cause in the wild, but perhaps your problem is different. –  Gilles Jan 10 '11 at 20:13

6 Answers 6

up vote 28 down vote accepted

Edit your "/etc/ssh/ssh_config" and comment out these lines:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
share|improve this answer
+1 Nice answer! (1) Is it a normal speed for ssh login connection to take the time of the cursor flashing 7 times? (2) Why does it work by commenting out GSSAPIAuthentication yes and GSSAPIDelegateCredentials no? @Tshepang –  Tim Jan 20 '12 at 0:21
@Tim (1) that's way too long... depending on the connection, I don't expect it to take over 2 seconds; (2) I have no idea, just that it works –  Tshepang Jan 23 '12 at 9:00
The default for GSSAPIAuthentication in most versions of OpenSSH is "no", but some distros set it to "yes" in the sshd_config and ssh_config files. If you don't need/use it, it slows down the connection / authentication handshake. –  tgharold Oct 31 '13 at 17:25
If LDAP/AD authentication is in use, won't disabling GSSAPI cause a simple bind to be used, potentially sending passwords over the network in plaintext? –  Shannon Jul 31 '14 at 17:15

I had this problem and resolved it by turning off Reverse DNS resolution in SSH.

So in sshd_config on the server change this:

 #UseDNS yes

to this:

UseDNS no
share|improve this answer
I did the change (though I had no commented-out UseDNS option), reset my ssh server, and still the same problem. –  Tshepang Jan 21 '11 at 12:16
@Tshe hmm, odd. The only speed problems I've ever had with SSH was due to this. –  Earlz Jan 22 '11 at 0:49
I was skeptical as I use to login using the IP address (home LAN), but this solution fixed my issue. For Google's sake, though it was occurring just after, the delay had nothing to do with the "key: /home/mylogin/.ssh/id_ecdsa ((nil))" message (when running ssh -vvv). –  Skippy le Grand Gourou May 19 '14 at 10:39

Have you verified your DNS setup?

Try the setting mdns off in /etc/host.conf.

This disables the mdns resolution and helped me a lot.


It seems gentoo is handling this a bit different. To disable multicast DNS lookups, you have to change the file /etc/nsswitch.conf.
There should be something like:

hosts:          files mdns

Change it to:

hosts:          files dns
share|improve this answer
+1 good idea. @Tshepang does ssh connect faster when you use hostname's IP directly? –  Tobias Kienzler Jan 10 '11 at 15:24
@tobias takes half as much time –  Tshepang Jan 10 '11 at 15:28
I'm getting /etc/host.conf: line 2: bad command mdns off'` when I run ssh user@hostname. –  Tshepang Jan 10 '11 at 16:42
Seems this is an outdated setting, since glibc 2.3.x (2006): forums.gentoo.org/viewtopic-t-476558-highlight-mdns.html. What are you using (OS, glic version)? –  Tshepang Jan 10 '11 at 16:53
You are telling it takes only half the time when you use the IP address. This means you have a problem with your name resolution (IP=>FQDN or FQDN=>IP). So first take a look at your DNS config and then try to find out whether you have a problem with ssh or not. –  Christian Jan 11 '11 at 6:50

Adding the host name to /etc/hosts can sometimes resolve this issue.

share|improve this answer
Works for a single hostname, but Earlz's solution is more generic (and fixes the same issue). –  Skippy le Grand Gourou May 19 '14 at 10:41

Also check if nscd is installed and running.

Not having a dns cache can increase the time it takes to resolve the PTR record (assuming that the ssh client is performing a dns reverse lookup for the server's IP address)

share|improve this answer

I have the same problem in the Windows 2008 R2 environment but "useDNS no" does not work.

I try adding to hosts file the IP and host of the connecting server and its faster by 30secs. Which makes me think that the resolution might be in DNS.

I try adding DNS servers but this doesnt resolve it.

My server have two DNS suffix. 1 for the corporate domain where the server belong (domain.com) and the other for its external interface connecting to a private network (domain.net).

DNS suffix order is domain.net first then domain.com next

My SFTP/SSH clients are in the the corporate domain. By the way problematic clients are from corporate domain.

What works for me is that I make domain.com first then domain.net second

The 2m30s connection delay before became 3-4s only .

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.