51

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)

[update]

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
9
  • 1
    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, 2011 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, 2011 at 16:59
  • 5
    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 'SO- stop being evil'
    Jan 10, 2011 at 19:52
  • @gil Thanks. I updated the question. I'll ask the admin to check for that UseDNS setting.
    – tshepang
    Jan 10, 2011 at 20:07
  • 3
    @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 'SO- stop being evil'
    Jan 10, 2011 at 20:13

9 Answers 9

Reset to default
35

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

GSSAPIAuthentication yes
GSSAPIDelegateCredentials no

Alternatively, having the following in SSH config (~/.ssh/config) also works:

GSSAPIAuthentication no
6
  • 3
    +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, 2012 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, 2012 at 9:00
  • 2
    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, 2013 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, 2014 at 17:15
  • Verify all the nameservers still exist in /etc/resolv.conf. If they don't, take them out. This resolved my issue.
    – technocrat
    Sep 21, 2017 at 11:52
33

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
5
  • 1
    I did the change (though I had no commented-out UseDNS option), reset my ssh server, and still the same problem.
    – tshepang
    Jan 21, 2011 at 12:16
  • 2
    @Tshe hmm, odd. The only speed problems I've ever had with SSH was due to this.
    – Earlz
    Jan 22, 2011 at 0:49
  • 1
    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, 2014 at 10:39
  • 2020 and we still had that problem :) for Googlers' sake: restart the sshd service afterwards before testing..
    – amyassin
    Apr 5, 2020 at 17:23
  • If you proxy-jump through another host on the same local network as the target, this can occur because the target tries to reverse lookup the jump hosts local IP.
    – Adam Lindberg
    Mar 9, 2021 at 16:05
7

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.

EDIT:

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
10
  • +1 good idea. @Tshepang does ssh connect faster when you use hostname's IP directly?
    – Tobias Kienzler
    Jan 10, 2011 at 15:24
  • @tobias takes half as much time
    – tshepang
    Jan 10, 2011 at 15:28
  • I'm getting /etc/host.conf: line 2: bad command mdns off'` when I run ssh user@hostname.
    – tshepang
    Jan 10, 2011 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, 2011 at 16:53
  • 1
    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, 2011 at 6:50
3

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

1
  • Works for a single hostname, but Earlz's solution is more generic (and fixes the same issue).
    – Skippy le Grand Gourou
    May 19, 2014 at 10:41
1

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)

0

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 .

0

Double check your /etc/hosts.

I have changed my hostname using hostnamectl set-hostname and updated IPv4 address in /etc/hosts, but forgot to update IPv6 address:

127.0.0.1              localhost
45.12.34.56            srv1.foobar.com
2a00:abc:123:6432::1   srv1.foobar.com
0

I had the same symptoms, but they seemed to be client related. In my case, using Putty as an SSH2 client I had to switch the 'Internet protocol version' under the connection menu from Auto to IPv4. I didn't investigate why Auto doesn't work faster.

0

If you use gpg-agent to cache ssh keys & you also run gnome-keyring you need to:

In a secure desktop environment (with hidepid) it is less problematic to just run ssh-agent as a systemd --user service. & enable ssh key caching in ~/.ssh/config:

Host *
  AddKeysToAgent yes

I use secure Ciphers / MACs / KexAlgorithms (256 / 512 bit only) in my remote sshd_config & also in my local ~/.ssh/config:

Debugging the slow connection with ssh -vvv user@host showed the ssh client trying lots of different combinations of keys & options.

To speed up the key exchange it helped to:

  • remove weak keys from the remote server (DSA / ECDSA)

  • set a default ssh key in my local ~/.ssh/config that matched my strict configuration:

Host *
  IdentityFile ~/.ssh/id_ed25519

With these changes the publickey became accepted within the same second.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .