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/

Gregory Colpart <reg@evolix.fr> writes:

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,

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.

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> writes:

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> writes:

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.

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