SSH with GSSAPIAuthentication option on SSH servers are very slow

I can confirm this problem. I experienced the same symptoms, or rather my system did, and the above proposed workaround fixed the problem.

I hope this gets fixed one way or the other, because without the workaround, SSH was unusable.

confirmed; although setting GSSAPIAuthentication to no doesn't help.

I need 'ssh -vvv' output with some kind of indication of the point where it seems to hang for long periods of time.

(I can't reproduce this myself.)

I think someone fixed it, now I cant reproduce it too but i have a new version: 4.3p2-8ubuntu1

No sorry I mistoke the option in /etc/ssh/ssh_config, the bug is still here.
This is the -vvv trace:

mik@goa:~$ ssh root@10.31.192.11
Last login: Mon Mar 5 15:53:40 2007 from goa.fastwebit.ofc
Linux carlinux 2.6.17-11-386 #2 Thu Feb 1 19:50:13 UTC 2007 i686
  / ____/____ _ _____ / /(_)____ __ __ _ __ / __ \ / ___/
 / / / __ `// ___// // // __ \ / / / /| |/_/ / / / / \__ \
/ /___ / /_/ // / / // // / / // /_/ /_> < / /_/ /_ ___/ /_
\____/ \__,_//_/ /_//_//_/ /_/ \__,_//_/|_| \____/(_)/____/(_)
root@carlinux:~# logout
Connection to 10.31.192.11 closed.
mik@goa:~$ ssh mmarcucc@10.30.68.35
mmarcucc@10.30.68.35's password:

mik@goa:~$
mik@goa:~$
mik@goa:~$ ssh -vvv mmarcucc@10.30.68.35
OpenSSH_4.3p2 Debian-8ubuntu1, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.30.68.35 [10.30.68.35] port 22.
debug1: Connection established.
debug1: identity file /home/mik/.ssh/identity type -1
debug3: Not a RSA1 key file /home/mik/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/mik/.ssh/id_rsa type 1
debug1: identity file /home/mik/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1
debug2: fd 3 setting O_NONBLOCK

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
A parameter was malformed
Validation error

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
A parameter was malformed
Validation error

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,<email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysa...

I'm having the same problem here. I've attached an ssh -vvv log, timing info is as follows:

Start: Tue Mar 6 22:44:54 GMT 2007
Hung at line 59 until: Tue Mar 6 22:45:45 GMT 2007
Hung at line 65 until: Tue Mar 6 22:46:33 GMT 2007
Then proceeds normally.

Disabling GSSAPIAuthentication fixes the problem for me too.

Hi all,

Im getting a similar problem but instead of just the login prompt on a local 100Mbps network the SSH clients are up to work on a whooping 45kbps.
Anyone has had any problem like this or is this just a problem with the login taking too long ?

James,

That host does not have a FQHN right?

I believe the problem is that the GSSAPI authenticion tries to look up the hostname
and the timeout problems is from failing that. Which is why it also fails (sometimes) when ssh:ing to a numeric host address

I am having this problem also, and "GSSAPIAuthentication no" didn't help at all. I have version 4.3p2-8ubuntu1.

Here is what I got, it hangs on "debug2: we sent a keyboard-interactive packet, wait for reply" for about 10 seconds.

ssh -vvv root@192.168.0.3
OpenSSH_4.3p2 Debian-8ubuntu1, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.3 [192.168.0.3] port 22.
debug1: Connection established.
debug1: identity file /home/andy/.ssh/identity type -1
debug1: identity file /home/andy/.ssh/id_rsa type -1
debug1: identity file /home/andy/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,<email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,<email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,<email address hidden>,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,<email address hidden>,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,<email address hidden>,zlib
debug2: kex_parse_kexinit: none,<email address hidden>,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,<email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,<email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,<email address hidden>,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,<email address hidden>,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expec...

Dear fellows,

I am also suffering this problem, although in my case disabling the GSSAPIAuthentication seems to help (only tested once). I'm attaching the ssh -vvv log with the GSSAPIauthentication on. BTW: I use password authentication, instead of key/passphrase.

It might be interesting to note that, from my debian etch PC (also openssh v. 4.2p8), ssh login is quick. In this case, there are no GSSAPI related options in /etc/ssh/ssh_config (dist-upgraded from sarge).

In case you want the ssh -vv log differences with GSSAPI authentication off, I'm attaching that in the next post.

As promised, here goes the log with GSSAPI authentication disabled.

Sorry for replying again, but the thing all these logs seem to have in common is that all of us are ssh'ing to a private network, instead of a "public IP" (sorry for the missnomer): michelem and me are trying to connect to a 10.*.*.* IP and AndrewLawrence is doing the same for a 192.168.*.*, typical for home LAN's.

However, connecting to the Debian box (it has an IP reachable from everywhere) is as fast as ever.

I have the same problem with a new installation of Feisty Fawn. Setting "GSSAPIAuthentication no" works for me. Alternatively, it also works to add an entry for the host to /etc/hosts. (Something to do with the reverse DNS lookup I believe.) In case it's relevant, the server I'm connecting to does not return a PTR record when using the command host <hostname>

I can confirm this issue over WWW and LAN.

I have 2 SSH servers, one here, one elsewhere, and it typically takes 5 minutes to log in to remote SSH, and 2 for the local one.

Turned off GSSAPIAuthentication and voila, 5 seconds to log in to remote server, 2 for local one.

Please fix.

Attached is my output from the following commands:

cat /etc/ssh/ssh_config | tail
ssh -vvv chrism@10.10.20.1 exit
ssh -vvv <email address hidden> exit

This should confirm the bug.

Here is said file.

Look for the lines ********** HANG HERE *********

I've been encountering this issue and tearing my hair out over this. The reason being I've set my grace login period to a short 15 seconds. This means this issue manifests as not being able to connect at all.

This is a stock Dapper SSHD install being connected to via a stock Feisty SSHClient install. Disabling the GSSAPI config at least enables me to connect to my server without a 'Connection closed by ...'

Hi everyone,
I had a similar problem, and setting GSSAPIAuthentication to no did NOT help.
I disabled mDNS from the nsswitch.conf file on the client and now the problem is solved:
In /etc/nsswitch.conf, I replaced :

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

with

hosts: files dns

Let me know if this helps.
Ben

@Ben

nsswitch.conf fix corrected the issue for me (at least for my LAN).

Setting GSSAPIAuthentication to no sped up my time-to-SSH-login-prompt to 1-2 seconds from 5-6. Thanks.

I also had to edit nsswitch.conf
This fix worked for me, i am now able to connect and the connection is much faster.

In /etc/nsswitch.conf, I replaced :

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

with

hosts: files dns

Note both the client and server are Ubuntu boxes connecting to an Active Directory server via Samba winbind Kerberos 5 authentication. I believe this has something to do with the problem.

Another user faced similar performance problems with SSH, documented in bug #84849. Again, the problem was solved by disabling mdns4_minimal resolution in nsswitch.conf.

So far, some people benefited from disabling GSSAPI-Authentication, some others had to disable mDNS to regain acceptable performance. Do we have two separate issues here?

Same here.

Again resolved by a disabled GSSAPI-Authentication.

I have one precision : between two ubuntu feisty, the problem wasn't really pronouced; but between an ubuntu and a Red Hat 4 this is terrible (about 3/4 minutes...).

I was connecting to a sshd on a Debian Etch which ran on the same machine under VMWare.
The guest OS has a 192.168.x.y type IP (dhcp from VMWare) on a separate virtual interface.

I applied William's solution (https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/84899/comments/22).

In /etc/nsswitch.conf, I replaced :

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

with

hosts: files dns

From 5-10 seconds I now get less than one second wait time before the password prompt is shown.

No other edits to ssh_config were needed.

I have the same problem with slow SSH connects to LAN IPs.
If
   GSSAPIAuthentication yes
in my ssh/ssh_config there are three places where ssh waits for a long time:

<snip>
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2 Debian-8ubuntu1
debug1: match: OpenSSH_4.3p2 Debian-8ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1
debug2: fd 3 setting O_NONBLOCK
[...HERE...] <------------------------------- NOTICE!

debug1: Miscellaneous failure
No credentials cache found
[...HERE...] <------------------------------- NOTICE!
<snip>
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/identity ((nil))
debug2: key: /root/.ssh/id_rsa ((nil))
debug2: key: /root/.ssh/id_dsa ((nil))
[...AND HERE] <------------------------------- NOTICE!

When I change ssh_config to
   GSSAPIAuthentication no
I get rid of the first two stops but the last one remains.

It even remains after modify nsswitch.conf as described above.

Any other ideas on how to get rid of the slow ssh connect?

I confirm this situation. If I open a ssh connection over openvpn to the destination host, then i have to wait 10 seconds. After i create ~/config and insert:

GSSAPIAuthentication no

the initial connection is finished in about 1 second.

Thank you, everyone for your comments. I had two hangs. Installing krb5-config stopped one, adding an /etc/hosts entry for the client on the host stopped the other one.

I don't see this myself, but I just observed it on sabdfl's machine and saw that disabling GSSAPIAuthentication eliminated the delays (which lasted several seconds)

For me either disabling GSSAPIAuthentication or changing nsswitch fixes it.

changing nsswitch to "files dns mdns4" didn't help - I had to change it to "files dns"

Neither fix to the config files works for me on 7.04
Meanwhile, I can use putty to connect from Windows.
The host is a RedHat linux server.

Debian testing has the same problem.

I had this problem with a fresh install of feisty. Found the solution here:
http://ubuntuforums.org/showthread.php?t=377212&highlight=ssh+delay

from comment #9:

If you got to System>Administration>Network and click the "General" tab there is a new option that says
"Scan for available services and advertise . . ."
Mine was checked by default. Unchecking it removed the delay.

Unchecking the box removed the delay for me. Should this be checked by default? If I go to this screen it says this is a potential security risk, not to mention a big annoyance when trying to ssh into remote computers.

Same problem, tried both fixes but neither resolved. My problem apparently was in the reverse dns. Adding entries for each system into /etc/hosts worked perfect. I reverted the change to /etc/ssh/ssh_config and reenabled mdns and the speed stayed fast. Check the basics first, this was my fix, your milage may vary.

127.0.0.1 localhost
10.0.0.13 lithium.domain.tld lithium
10.0.0.12 helium.domain.tld helium
10.0.0.13 hydrogen.domain.tld hydrogen

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

** If you do not have a domain name you can use .local or just hostnames.

Had same problem. An Ubuntu 7.04 running in VMWare Fusion where connecting from my mac was extermely slow. Neither of the two proposed fixes works, however above fix for setting with setting a host name for the client worked. In addition, I found that instead of inserting the hostname of the client into /etc/hosts you can also add set the following in the config:

UseDNS no

I'm not sure how this affects the security, but my virtual machine with ubuntu is not online so it works for me.

I have the same problem here with a CentOS 5 (Redhat Clone) running in a VMWare. I cannot connect via SSH between the virtual machine and its host. From the Feisty (Host), I see exactly what is described here, and the session hangs after "debug1: SSH2_MSG_KEXINIT sent" for a long time, and finally times out. None of the workarounds described here helps. In the other direction (initiating the session from the VMWare to the Ubuntu host), it already hangs a couple of lines earlier ("debug1: identity file /home/izzy/.ssh/id_dsa type -1". Any hints where else to look or what to toggle?

Btw: @Lars: Where do you put that "UseDNS no"? If I add that to my ~/.ssh/config, I simply run into an error because of an illegal keyword...

I see the same symptoms as Izzy, except my VMware system is OpenBSD. I cannot SSH in either direction. I can, however, SSH via an intermediate other system (Debian/Etch).

i.e.

Feisty -> OpenBSD - FAILS
OpenBSD -> Feisty - FAILS
Feisty -> Etch -> OpenBSD - OK

I commented the line

GSSAPIAuthentication yes

in /etc/ssh/ssh_conf

It worked for me. My ssh authentication is now much faster.
I use Ubuntu 'feisty'.

Further to my comment on 2007-08-23, I have more information. The misbehaviour clearly relates to non-ssh packages/config on the client system in question. I have two Feisty installs, both acting as clients to an OpenBSD server. One connects happily, the other hangs at "SSH2_MSG_KEXINIT sent" when using "ssh -vvv".

Both Feisty clients have the same SSH config, *exactly*, both in ~/.ssh and /etc/ssh/ssh_config

If the problem relates to a conflict with another package/library/something, I am in a position to test this, if anyone can suggest *what* to actually test!

[Expired for openssh (Ubuntu) because there has been no activity for 60 days.]

I had the same problem on my private network lately when I added a new machine.
I had forgotten to update the table for reverse dns requests with the ip of the new host.
Once fixed, I could ssh on the new host without trouble.

SOLVED for me.

I was having a 5-10 second delay when logging in via SSH. Here was my fix:

- On the client:
In /etc/ssh/ssh_config, set: 'GSSAPIAuthentication no'

-On the server:
In /etc/nsswitch.conf, change the 'hosts:' line to read this: 'hosts: files dns'

After those two changes, logins were smoking fast.

Here is an ssh -vvv trace of when I was having the problem, look for line that says "***LOGIN DELAY ":

OpenSSH_4.6p1 Debian-5build1, OpenSSL 0.9.8e 23 Feb 2007
debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Applying options for *

debug2: ssh_connect: needpriv 0

debug1: Connecting to ***HIDDEN*** port 22.

debug1: Connection established.

debug1: identity file /home/***HIDDEN***/.ssh/identity type -1

debug3: Not a RSA1 key file /home/***HIDDEN***/.ssh/id_rsa.

debug2: key_type_from_name: unknown key type '-----BEGIN'

debug3: key_read: missing keytype

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug2: key_type_from_name: unknown key type '-----END'

debug3: key_read: missing keytype

debug1: identity file /home/***HIDDEN***/.ssh/id_rsa type 1

debug1: identity file /home/***HIDDEN***/.ssh/id_dsa type -1

debug1: Remote protocol version 2.0, remote software version OpenSSH_4.6p1 Debian-5build1

debug1: match: OpenSSH_4.6p1 Debian-5build1 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_4.6p1 Debian-5build1

debug2: fd 3 setting O_NONBLOCK

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,<email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,<email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,<email address hidden>,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@o...

This is really an nss-mdns bug, reported here:

https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/94940

Yes, I agree with ed_p. Also for me, that is the problem.
For me, a simple "ssh server" took about 10 secs. Running with "ssh -o GSSAPIAuthentication=no server" brought that delay down to nothing. Disabling avahi on the client like this:
$ sudo /etc/init.d/avahi-daemon stop
Made it login without delay with or without GSSAPIAuthentication=no. Until the next reboot, where avahi will be restarted.
Disable avahi permanently by setting "AVAHI_DAEMON_START=1" in /etc/default/avahi-daemon worked for me. (Until I discover what avahi is and want to use it! :D)

This bug is ~2 years old and cripples ssh use pretty badly. People waste time hunting it down and working around it by disabling avahi or ssh's gss-api stuff. I just upgraded to Jaunty alpha and it's still the same.
Is there some mechanism to propose this be fixed before Jaunty is out (i'm not too familiar with this launchpad stuff)?

I've reproduced the problem on: Intrepid Minimal CD Install + ssh

There's no apparent avahi installed or activated

In that configuration, "-o GSSAPIAuthentication=no" on the client command line has no effect, nor does setting it in the server's ssh_config file (though why that would change anything, I have no idea). The only way to suppress the delay seems to be to put

UseDNS no

in the server's /etc/ssh/sshd_config

Erno, I have nominated the problem for jaunty, i.e. proposed that it be fixed before the release. To do that, simply click "Nominate for release" near the top of the bug page and select the release(s) you want to nominate the bug for.

I think the bug description is not very clear: there are situations in which disabling GSSAPIAuthentication on server side fix the issue (maybe because of DNS doesn't have a reverse resolution, as in my situation fixed just putting GSSAPIAuthentication to off on a server that doesn't have a reserve resolution as it has a prive IP ) and other not (as you can read from most comments).

This is still the case with Lucid.
I change to no in my local config and now ssh is faster.
I think it is important for user experience to set this to no by default and anyone needing it can then enable it manually. This is because this bug has now created the impression that ssh when using ubuntu/linux is slow or has a long delay. This is not good from a general experience point of view.

I don't think we should accept slow default settings...or at least ask the question during installation/configuration time.

Regards

Hi,

I have the same opinion as chifamba. People start thinking that SSH on Ubuntu is slow. I had also the same opinion before seeing this bug in Launchpad.

By the way, there is a line in /etc/ssh/ssh_config that reads:

# GSSAPIAuthentication no

and another line that reads:

    GSSAPIAuthentication yes

Obviously someone added the "GSSAPIAuthentication yes" when default is "no." Since commenting the line with "yes" fixed my problem (~10-15 sec vs. ~0-1 sec for login) I think the default should be restored.

This is such an easy fix, I am amazed the problem is still around with Lucid (not that there isn't some underlying problem that isn't an easy fix). Why not default to "no?"

This is nice. This bug has been going for three years about commenting or deleting a single line in the SSH config and the line is still there.

Comparing the output of "man ssh_config" on Fedora 12 and Ubuntu 10.10, near the beginning we can see the following paragraph in Ubuntu's page which does not appear in Fedora's:

"Note that the Debian openssh-client package sets several options as standard in /etc/ssh/ssh_config which are
     not the default in ssh(1):

           · SendEnv LANG LC_*
           · HashKnownHosts yes
           · GSSAPIAuthentication yes
"

Maybe we are ranting about this bug in Ubuntu's systems (Launchpad) but no one has complained in Debian bugtracker? Maybe Ubuntu just uses the upstream package from Debian, and we should notify Debian?

I answer myself: this bug was tracked in Debian:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409360

Strangely, chat about this problem in Debian seems to stop around 2007, and no one has complained since then. THe bug is still open, though.

I confirm this problem in Ubuntu 10.10. I experienced the exact symptoms as described in https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/416264, but I think the bug belongs to #84899.

Ubuntu uses the Debian package, as shown at the top of the attached file (personal information removed):
OpenSSH_5.5p1 Debian-4ubuntu4, OpenSSL 0.9.8o 01 Jun 2010

The remote server is running Red Hat, which has /etc/ssh/ssh_config with: GSSAPIAuthentication Yes

I have no access to modify the remote server's files. So, I think the problem is bigger than just Debian.

I created a user ~/.ssh/config file to contain:
GSSAPIAuthentication no

The work-around fixes the problem, access is very fast.

("cat /proc/version" will display the distro name, "uname -a" does not display the distro name.)

My previous post shows the results after modifying ~/.ssh/config to contain:
GSSAPIAuthentication no

(success)

this bug affect ubuntu 10.10 maverick

This bug is still affecting Ubuntu 11.10

Setting GSSAPIAuthentication no is still a viable workaround... but a pain in the butt because I have to look this up with each fresh install!!!

It has been 4 years. The only reason to have GSSAPIAuthentication option on is if you are running a Kerberos setup. Who the hell runs Kerberos nowadays anyway. Can we have this finally set to off by default or will it take another 4 years? This is disrupting an important service by switching on an obscure authentication option. What gives?

We, and a lot of other enterprise sites are using Kerberos, so we would like it to be on by default.

I just met problem like this. It prevented logging on to a server completely.

Here's a log:

ssh -vvv <email address hidden>
....
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
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

(time passes)

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

debug1: Unspecified GSS failure. Minor code may provide more information

debug1: Unspecified GSS failure. Minor code may provide more information

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/xxx/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
Connection closed by 12.34.56.78

After setting "GSSAPIAuthentication no" connection works fine.

I run into this with Ubuntu lucid frequently when connecting to CentOS systems. I have no local Kerberos configuration.

A good fix for me would be to have SSH check if kerberos is locally configured before trying to do Kerberos authentication. However I have no idea how feasible this approach is.

There is no file /etc/krb5.conf on my system, neither is the krb5-config package installed.

This bug still affects 12.04 precise beta.

Hello Customer

Don't hesitate. We do our best to satisfy our customers and ensure fast delivery and excellent service. If you receive a damaged watch we will ship another one to you free of charge.
Make your order before the prices go up.

**************************************************************************************
Today I received my two watches. Both watches were spectacular, you guys did a wonderful job and I will definitely recommend you to all my friends!
Thankee!
                     Marla Friedman
**************************************************************************************

Click here ---> http://ranoa.ru

Also reproduces in the released version of 12.04 (64-bit desktop edition), as follows:

30-second delay before the password prompt is displayed when ssh'ing directly to the IP address (no DNS lookup involved) of a machine on the same network segment. Adding "GSSAPIAuthentication no" to ~/.ssh/config removes the delay.

I encountered this same problem (with the same cure) a couple of years ago in a different corporate network environment.

Is there any change the default configuration could be changed to accommodate this?
Those of our users running e.g. Ubuntu (12.04) experience this frustratingly long delay, and just assume it's our servers being very slow.
Luckily, our Linux-users are generally more computer savvy than others, so telling them to edit a configuration file is normally not a problem.

Ok, I understand the reason to keep it on as default, which is also useful on our case, where we actually have a kerberized environment, but there must be some way to reduce this huge login delay, or at least make it easier to it turn on/off than "ssh -o GSSAPIAuthentication=... user@hostname"

I use plenty of servers without Kerberos and I never see this. I don't think it's clear that having GSSAPIAuthentication on by default is the problem. I think it's more likely that there is some other cause, and turning GSSAPIAuthentication off is merely a workaround.

I also suspect that reporters have a number of different underlying problems. One of them might be reverse DNS lookups timing out.

I also just found some clues that it might be caused by reverse DNS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409360

Disabling mdns4 hosts lookup in /etc/nsswitch.conf indeed seems to fix the problem, so I will probably settle with that workaround, keeping GSSAPIAuthentication turned on.

So here's a list of the workarounds:

On the client:
# disable reverse lookups in kerberos
echo $'[libdefaults]\n\trdns=false' |sudo tee -a /etc/krb5.conf
# Alternatively, remove mdns, mdns4, mdns6 from nsswitch
/etc/nsswitch.conf
# Or disable GSSAPIAuthentication in ~/.ssh/config or /etc/ssh/ssh_config or with the -o flag
GSSAPIAuthentication=no

On the server:
GSSAPIAuthentication=no in /etc/ssh/sshd_config

Fixes that require coding would be the one at http://bugs.debian.org/409360#40 which seems simple enough.
Paliatives would be a cache of notfound results in avahi or in sshd (so that the 5 seconds Avahi timeout isn't repeated for the four times ssh tries name resolution).

This is still an issue with Ubuntu 12.10.

matt-walston (#33) solution worked for me. I'm on Ubuntu 12.04.3 connecting to RedHat ssh server.

"My problem apparently was in the reverse dns. Adding entries for each system into /etc/hosts worked perfect."