How to speed my too-slow ssh login?

Question

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

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 '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
@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
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

score 35 · Answer 1 · edited Jul 09 '21 at 11:01

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

edited Jul 09 '21 at 11:01

tshepang

64,472
86
223
290

answered Jan 21 '11 at 03:51

Alvaro Araos

351
2
2

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

score 33 · Answer 2 · edited Feb 08 '13 at 00:39

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

edited Feb 08 '13 at 00:39

Clayton Stanley

512
4
8

answered Jan 21 '11 at 04:52

Earlz

2,184
2
16
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

Christian · Answer 3 · 2011-01-11T07:00:41.267

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

edited Jan 11 '11 at 07:00

answered Jan 10 '11 at 14:24

Christian

1,571
9
10

+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): https://forums.gentoo.org/viewtopic-t-476558-highlight-mdns.html. What are you using (OS, glic version)? – tshepang Jan 10 '11 at 16:53
What do you mean by *Have you verified your DNS setup?* – tshepang Jan 10 '11 at 16:54
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 '11 at 06:50
Added an example for gentoo. Hope this works for you. – Christian Jan 11 '11 at 07:01
I had `hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4` and changed it to `hosts: files dns`. It's now instant. Is that kool? – tshepang Jan 11 '11 at 11:26
Also, can you comment on my glibc note. – tshepang Jan 11 '11 at 11:26
OS is: SLES 11 SP1, glibc version 2.11.1 – Christian Jan 12 '11 at 07:29

score 3 · Answer 4 · edited Mar 25 '13 at 14:58

3

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

edited Mar 25 '13 at 14:58

Michael Mrozek

91,316
38
238
232

answered Mar 25 '13 at 14:51

Don Mclachlan

131
2

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

Jorge V. · Answer 5 · 2013-05-03T14:03:53.743

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)

edited May 03 '13 at 14:03

answered May 02 '13 at 23:19

Jorge V.

419
5
12

score 0 · Answer 6 · edited May 27 '15 at 11:04

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 .

score 0 · Answer 7 · answered Apr 17 '20 at 02:30

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

score 0 · Answer 8 · answered Nov 22 '20 at 05:32

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.

answered Nov 22 '20 at 05:32

Hubert Schumacher

131
3

score 0 · Answer 9 · answered Oct 26 '21 at 04:38

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

deactivate the ssh component in gnome-keyring.

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.

How to speed my too-slow ssh login?

9 Answers9

Linked

Related