Debian Bug report logs - #409360
GSSAPI authentication is sometimes slow with Avahi

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Gregory Colpart <reg@evolix.fr>

To: submit@bugs.debian.org

Subject: openssh-client: Disabling GSSAPIAuthentication option by default

Date: Fri, 2 Feb 2007 12:18:48 +0100

Package: openssh-client
Version: 1:4.3p2-8
Severity: wishlist

Hello,

Connections with GSSAPIAuthentication option on non-kerberos SSH servers
are very slow (3 or 4 seconds on local servers).

Here is debugging messages :
#####
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
####

This is probably a problem for a majority of users and I request
for disabling GSSAPIAuthentication option by default (or giving
debconf choice).

Regards,
--
Gregory COLPART <reg@evolix.fr>  GnuPG:1024D/C1027A0E
Evolix - Informatique et Logiciels Libres http://www.evolix.fr/

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)

Versions of packages openssh-client depends on:
ii  adduser  3.102                           Add and remove users and groups
ii  debconf  1.5.11                          Debian configuration management sy
ii  dpkg     1.13.25                         package maintenance system for Deb
ii  libc6    2.3.6.ds1-10                    GNU C Library: Shared libraries
ii  libcomer 1.39+1.40-WIP-2006.11.14+dfsg-1 common error description library
ii  libedit2 2.9.cvs.20050518-2.2            BSD editline and history libraries
ii  libkrb53 1.4.4-6                         MIT Kerberos runtime libraries
ii  libncurs 5.5-5                           Shared libraries for terminal hand
ii  libssl0. 0.9.8c-4                        SSL shared libraries
ii  passwd   1:4.0.18.1-6                    change and administer password and
ii  zlib1g   1:1.2.3-13                      compression library - runtime

openssh-client recommends no packages.

-- no debconf information

Message #10 received at 409360@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Gregory Colpart <reg@evolix.fr>

Cc: 409360@bugs.debian.org

Subject: Re: Bug#409360: openssh-client: Disabling GSSAPIAuthentication option by default

Date: Fri, 02 Feb 2007 11:47:14 -0800

Gregory Colpart <reg@evolix.fr> writes:

> Package: openssh-client
> Version: 1:4.3p2-8
> Severity: wishlist

> Connections with GSSAPIAuthentication option on non-kerberos SSH servers
> are very slow (3 or 4 seconds on local servers).

This should only be if your DNS or Kerberos configuration is broken.  If
you have no Kerberos configuration, it will fail extremely quickly.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #15 received at 409360@bugs.debian.org (full text, mbox, reply):

From: Gregory Colpart <reg@evolix.fr>

To: 409360@bugs.debian.org

Cc: Gregory Colpart <reg@evolix.fr>

Subject: Re: Bug#409360: openssh-client: Disabling GSSAPIAuthentication option by default

Date: Tue, 6 Feb 2007 18:44:10 +0100

On Fri, Feb 02, 2007 at 11:47:14AM -0800, Russ Allbery wrote:
> Gregory Colpart <reg@evolix.fr> writes:
> 
> > Package: openssh-client
> > Version: 1:4.3p2-8
> > Severity: wishlist
> 
> > Connections with GSSAPIAuthentication option on non-kerberos SSH servers
> > are very slow (3 or 4 seconds on local servers).
> 
> This should only be if your DNS or Kerberos configuration is broken. If
> you have no Kerberos configuration, it will fail extremely quickly.

After some tests, I understand that the problem is when
GSSAPIAuthentication option enabled AND Avahi daemon started
(it's case of an Etch "out of the box" for example) AND no
reverse record for IP address of SSH server.

With "GSSAPIAuthentication yes", I see reverse DNS query for the
IP address of SSH server after I start "ssh server", and with
Avahi daemon, connection lags during 3 or 4 seconds before to
continue (during mDNS PTR queries).

Regards,
-- 
Gregory Colpart <reg@evolix.fr>  GnuPG:1024D/C1027A0E
Evolix - Informatique et Logiciels Libres http://www.evolix.fr/

Message #20 received at 409360@bugs.debian.org (full text, mbox, reply):

From: Moritz Augustin <software@moritz-augustin.de>

To: 409360@bugs.debian.org

Subject: Re: Bug#409360: openssh-client: Disabling GSSAPIAuthentication option by default

Date: Fri, 30 Mar 2007 20:03:11 +0200

I would also like to see the option disabled by default, because I think most 
of the users dealing with Kerberos authentication issues know about the 
neccessary config parts.
People (like me) are wondering why connecting to local servers (without DNS) 
is that slow. 10 seconds per connection attempt.

It's not that it's not possible to change it (but you have to know how to 
debug ssh to get the error message which leads with a search engine to some 
users with the same problem. It's that it would be more comfortable to 
unexperienced users.

Message #25 received at 409360@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Moritz Augustin <software@moritz-augustin.de>, 409360@bugs.debian.org

Cc: Russ Allbery <rra@debian.org>

Subject: Re: Bug#409360: openssh-client: Disabling GSSAPIAuthentication option by default

Date: Fri, 30 Mar 2007 19:28:20 +0100

On Fri, Mar 30, 2007 at 08:03:11PM +0200, Moritz Augustin wrote:
> I would also like to see the option disabled by default, because I think most 
> of the users dealing with Kerberos authentication issues know about the 
> neccessary config parts.
> People (like me) are wondering why connecting to local servers (without DNS) 
> is that slow. 10 seconds per connection attempt.

I think it may be slightly unfair to blame GSSAPIAuthentication for
this. It happens that ssh does a reverse DNS lookup on the
GSSAPIAuthentication path, but that's essentially incidental, and it
doesn't seem to me that it would be fundamentally impossible to fix.
It's compounded by the presence of avahi and the fact that its reverse
DNS lookups are very slow, of course; one solution that was suggested to
me was to change this line in /etc/nsswitch.conf:

  hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4

... to:

  hosts:          files mdns4_minimal [NOTFOUND=return] dns

I would like to avoid the extra reverse DNS lookup if possible, though.
I looked into the source and couldn't entirely see what was going on, as
a chunk of it was buried in the bowels of krb5. Russ, do you have any
ideas here?

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #30 received at 409360@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Colin Watson <cjwatson@debian.org>

Cc: Moritz Augustin <software@moritz-augustin.de>, 409360@bugs.debian.org

Subject: Re: Bug#409360: openssh-client: Disabling GSSAPIAuthentication option by default

Date: Fri, 30 Mar 2007 12:32:48 -0700

Colin Watson <cjwatson@debian.org> writes:

> I would like to avoid the extra reverse DNS lookup if possible, though.
> I looked into the source and couldn't entirely see what was going on, as
> a chunk of it was buried in the bowels of krb5. Russ, do you have any
> ideas here?

Do we know which lookup in particular is hanging?  I had originally
thought that it was the lookups for the KDCs, but it sounds like that may
not be the case.  That's good news -- there isn't much that can be done
about the KDC lookups without some longer-term upstream projects, but if
it's something else, it may be easier to fix.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #35 received at 409360@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Russ Allbery <rra@debian.org>, 409360@bugs.debian.org

Cc: Moritz Augustin <software@moritz-augustin.de>

Subject: Re: Bug#409360: openssh-client: Disabling GSSAPIAuthentication option by default

Date: Sat, 31 Mar 2007 00:21:29 +0100

On Fri, Mar 30, 2007 at 12:32:48PM -0700, Russ Allbery wrote:
> Colin Watson <cjwatson@debian.org> writes:
> > I would like to avoid the extra reverse DNS lookup if possible, though.
> > I looked into the source and couldn't entirely see what was going on, as
> > a chunk of it was buried in the bowels of krb5. Russ, do you have any
> > ideas here?
> 
> Do we know which lookup in particular is hanging?  I had originally
> thought that it was the lookups for the KDCs, but it sounds like that may
> not be the case.  That's good news -- there isn't much that can be done
> about the KDC lookups without some longer-term upstream projects, but if
> it's something else, it may be easier to fix.

It's the one from gss_import_name (called from ssh_gss_import_name), I
believe.

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #40 received at 409360@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Colin Watson <cjwatson@debian.org>

Cc: 409360@bugs.debian.org, Moritz Augustin <software@moritz-augustin.de>

Subject: Re: Bug#409360: openssh-client: Disabling GSSAPIAuthentication option by default

Date: Fri, 30 Mar 2007 16:32:36 -0700

Colin Watson <cjwatson@debian.org> writes:
> On Fri, Mar 30, 2007 at 12:32:48PM -0700, Russ Allbery wrote:

>> Do we know which lookup in particular is hanging?  I had originally
>> thought that it was the lookups for the KDCs, but it sounds like that
>> may not be the case.  That's good news -- there isn't much that can be
>> done about the KDC lookups without some longer-term upstream projects,
>> but if it's something else, it may be easier to fix.

> It's the one from gss_import_name (called from ssh_gss_import_name), I
> believe.

Ah, yes.  Which calls krb5_sname_to_principal to try to figure out what
credentials to attempt to acquire, which in turn does:

            struct addrinfo *ai, hints;
            int err;
            char hnamebuf[NI_MAXHOST];

            /* Note that the old code would accept numeric addresses,
               and if the gethostbyaddr step could convert them to
               real hostnames, you could actually get reasonable
               results.  If the mapping failed, you'd get dotted
               triples as realm names.  *sigh*

               The latter has been fixed in hst_realm.c, but we should
               keep supporting numeric addresses if they do have
               hostnames associated.  */

            memset(&hints, 0, sizeof(hints));
            hints.ai_family = AF_INET;
        try_getaddrinfo_again:
            err = getaddrinfo(hostname, 0, &hints, &ai);
            if (err) {
                if (hints.ai_family == AF_INET) {
                    /* Just in case it's an IPv6-only name.  */
                    hints.ai_family = 0;
                    goto try_getaddrinfo_again;
                }
                return KRB5_ERR_BAD_HOSTNAME;
            }
            remote_host = strdup(ai->ai_canonname ? ai->ai_canonname : hostname);
            if (!remote_host) {
                freeaddrinfo(ai);
                return ENOMEM;
            }

            if (maybe_use_reverse_dns(context, DEFAULT_RDNS_LOOKUP)) {
                /*
                 * Do a reverse resolution to get the full name, just in
                 * case there's some funny business going on.  If there
                 * isn't an in-addr record, give up.
                 */
                /* XXX: This is *so* bogus.  There are several cases where
                   this won't get us the canonical name of the host, but
                   this is what we've trained people to expect.  We'll
                   probably fix it at some point, but let's try to
                   preserve the current behavior and only shake things up
                   once when it comes time to fix this lossage.  */
                err = getnameinfo(ai->ai_addr, ai->ai_addrlen,
                                   hnamebuf, sizeof(hnamebuf), 0, 0, NI_NAMEREQD);
                freeaddrinfo(ai);
                if (err == 0) {
                    free(remote_host);
                    remote_host = strdup(hnamebuf);
                    if (!remote_host)
                        return ENOMEM;
                }
            }

You can turn off the reverse DNS lookup by setting rdns to false in
[libdefaults] in krb5.conf, but this means that the Kerberos library
doesn't canonicalize the hostname for you, which is a change in behavior.
As the comment notes, the Kerberos library really shouldn't be doing this,
but it's been done this way for so long that it's a disruptive change to
stop.  This is really the wrong behavior for SSH in general, since SSH has
its own concept of host canonicalization that's handled through local
configuration, but Kerberos doesn't know it's being called by SSH.

However, before calling this function, gss_import_name creates a Kerberos
context, which means that this should all fail much earlier if one doesn't
have a krb5.conf file.  So people who don't have krb5-config installed
won't see this, even if reverse DNS is broken.  Unfortunately, the code
has no idea whether you have a ticket cache until much later, so if you
have the configuration available, this will all happen even if you don't
have Kerberos tickets (I think).

Personally, I think this bug lies with whatever package is installing a
broken reverse DNS setup that not only doesn't work but that takes forever
to time out.  But I realize that it's annoying to people and users don't
really care *where* the problem is coming from.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #47 received at 409360@bugs.debian.org (full text, mbox, reply):

From: Jesse Hathaway <jesse@mbuki-mvuki.org>

To: 409360@bugs.debian.org

Subject: GSSAPIAuthentication should be disabled by default

Date: Thu, 26 Oct 2023 12:14:47 -0500

I just ran into this issue when sshing to a server with GSSAPIAuthentication
enabled. Even though I am not using GSSAPI auth, Debian's default on the client
side added 15s to the login time. I agree with other folks that GSSAPI auth is
unusual and should be disabled by default since it may cause significant delays.

# With GSSAPIAuthentication on
$ time ssh -v foo hostname
<snip>
debug1: Next authentication method: gssapi-with-mic
debug1: No credentials were supplied, or the credentials were
unavailable or inaccessible
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)
debug1: No credentials were supplied, or the credentials were
unavailable or inaccessible
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)
<snip>
real    0m15.204s
user    0m0.010s
sys 0m0.011s

# With GSSAPIAuthentication off
$ time ssh -v foo hostname
real    0m0.195s
user    0m0.014s
sys     0m0.007s

Send a report that this bug log contains spam.