ssh client pauses during GSS negotiation due to delay on reverse lookup in avahi

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately, we can't fix it because your description didn't include enough information. You may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem. We have instructions on debugging some types of problems at http://wiki.ubuntu.com/DebuggingProcedures.
At a minimum, we need:
1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).
Thanks!

When reporting bugs in the future please use apport, either via the appropriate application's "Help -> Report a Problem" menu or using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

Excuse me Chuck but the problem is clear.
When you do
ssh -v SERVER.DOMAIN

you obtain an output similar to the following:
"
OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to wall [141.250.199.62] port 22.
debug1: Connection established.
debug1: identity file /home/marcop/.ssh/identity type -1
debug1: identity file /home/marcop/.ssh/id_rsa type -1
debug1: identity file /home/marcop/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, 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.7p1 Debian-8ubuntu1.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'wall' is known and matches the RSA host key.
debug1: Found key in /home/marcop/.ssh/known_hosts:87
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found

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

debug1: Next authentication method: publickey
debug1: Trying private key: /home/marcop/.ssh/identity
debug1: Trying private key: /home/marcop/.ssh/id_rsa
debug1: Trying private key: /home/marcop/.ssh/id_dsa
debug1: Next authentication method: password
"

There is no crash and no way to report it via apport.
I don't know what "Unspecified GSS failure" means. I have no kerberos system installed in my network (maybe could be this?).

However my problem was related to the fact that connecting to a server via ssh, apart from displaying the error indicated above (GSS failure), it took to long. I found that the problem was related to the fact that GSSAPIAuthentication was on by default on ssh server and the server had no reverse dns IP (it has a private address). Disabling GSSAPIAuthentication fixed the issue for me.

I obtain the same error (GSS failure) also connecting to other server that have correct DNS config and GSSAPIAuthentication enabled but in these servers I don't realize about the error because of there is no delay in the connection (thanks to right DNS direct and reverse loookup).

I say again that I don't know GSSAPI so if the error could be related to the fact that I have no kerberos system we could mark the bug as "invalid" or similar.

Same fault in 9.10 connecting to a CentOS 5.3 server.

debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
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: Next authentication method: publickey

Connecting to such servers from Ubuntu introduces an extensive delay that you don't get if you connect to such servers directly from a CentOS box.

The problem is triggered by the delay on reverse lookups that aren't answered due to the avahi configuration of Ubuntu desktops.

The 'Unspecified GSS failure' is a red herring. That is normal if you don't have Kerberos installed.

So it couldn't be a bug but an expected behavior. I don't know why GSSAPI auth needs reverse lookup but one could argue that you have to set right direct and reverse dns config in order to use SSH. If you haven't it (as in my situation) the problem could be related to you (and me :-))
Obviously you can disable GSSAPI auth (if you have access to SSH server) and, personally, I think it shouldn't enabled by default (even if many distro, as RH, do it).
The suggest could be: enable it, by default, in a server distro (Ubuntu Server) and disable it, by default, in the desktop release.

The DNS server is returning 'NXDomain' correctly. What is taking the
time is the Multicast AVAHI lookups.

You get the same delay if you ssh to an IP address.

The delay is a function of the AVAHI setup.

2009/11/11 marco.pallotta <email address hidden>:
> So it couldn't be a bug but an expected behavior. I don't know why GSSAPI auth needs reverse lookup but one could argue that you have to set right direct and reverse dns config in order to use SSH. If you haven't it (as in my situation) the problem could be related to you (and me :-))
> Obviously you can disable GSSAPI auth (if you have access to SSH server) and, personally, I think it shouldn't enabled by default (even if many distro, as RH, do it).
> The suggest could be: enable it, by default, in a server distro (Ubuntu Server) and disable it, by default,  in the desktop release.
>
> --
> ssh client pauses during GSS negotiation due to delay on reverse lookup in avahi
> https://bugs.launchpad.net/bugs/416264
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Neil Wilson

Could this be a duplicated of Bug #84899 ?

Just experienced this with a 8.04 ssh client talking to a CentOS ssh server. Turning off GSSAPIAuthentication avoids the delay.

As far as I know, everything is hunky-dory when connecting to an Ubuntu box (which I've done up until now). Connecting to joyent.us was a pain, until this workaround.

Interesting...

I can replicate this problem on ubuntu 10.10, configuring ssh not to do GSSAPIAuthentication stops it from taking so long to authenticate, thank you for the workaround.

I also confirm this problem on 10.10 and successfully applied the work-around. Additionally, I reported this problem and fix in Bug #84899 as suggested in comment #8: https://bugs.launchpad.net/openssh/+bug/84899/comments/54.

Ubuntu uses the Debian ssh package, so perhaps this bug should be merged with #84899?