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
tshepang
  • 65,642
  • 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 '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
  • 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 '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
  • 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 '11 at 20:13
  • @gil Does that mean that UseDNS is no longer valid option? – tshepang Jan 10 '11 at 20:18
  • @Tshepang: UseDNS no is a good idea most of the time (but in a managed network where the admin can trust the DNS UseDNS yes can be useful). I'd wait and see what the admin says. – Gilles 'SO- stop being evil' Jan 10 '11 at 20:33
  • @gilles What ssh client are you using? I use OpenSSH. – tshepang Jan 11 '11 at 08:43
  • Remember to restart the ssh server, see http://askubuntu.com/questions/103889/how-do-you-stop-restart-ssh and http://www.cyberciti.biz/faq/howto-start-stop-ssh-server/ – Dor Jan 27 '14 at 09:26

9 Answers9

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
tshepang
  • 65,642
  • 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 '12 at 00: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 09: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 '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
  • Verify all the nameservers still exist in /etc/resolv.conf. If they don't, take them out. This resolved my issue. – technocrat Sep 21 '17 at 11:52
  • The GSSAPI authentication attempt requires some extra DNS lookups. The root cause for significant wait time at SSH authentication is often a DNS lookup that is timing out. – telcoM Apr 17 '20 at 06:34
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
Earlz
  • 2,264
  • 2
  • 17
  • 12
  • 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 '11 at 12:16
  • 2
    @Tshe hmm, odd. The only speed problems I've ever had with SSH was due to this. – Earlz Jan 22 '11 at 00: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 '14 at 10:39
  • 2020 and we still had that problem :) for Googlers' sake: restart the sshd service afterwards before testing.. – amyassin Apr 05 '20 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 09 '21 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
Christian
  • 1,591
2

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

Michael Mrozek
  • 93,103
  • 40
  • 240
  • 233
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)

Jorge V.
  • 419
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 .

Anthon
  • 79,293
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.