ssh does not authenticate against kerberos

[Thomas Schweikle]

sshd is set up to authenticate using GSSAPI, but this never succeeds, falling back to any other configured authentication method. If all are forbidden, authentication fails without giving a useful reason.

On a local(!) system assume:
user test exists, krb5 is running fine, PAM is set up to use krb5. After loging in:

% ssh -l test 192.168.1.111
$ klist
Ticket cache: FILE:/tmp/krb5cc_2023
Default principal: <email address hidden>

Valid starting Expires Service principal
11/15/10 10:22:38 11/15/10 20:22:38 <email address hidden>
        renew until 11/16/10 10:22:35

Now that I have a ticket, I'd awaited to be automaticaly authenticated to log on on the very same server using ssh
$ ssh 192.168.1.111
test@192.168.1.111's password:

I am asked the password! Bad. Same with "-v":
$ ssh -v 192.168.1.111
OpenSSH_5.5p1 Debian-4ubuntu4, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.111 [192.168.1.111] port 22.
debug1: Connection established.
debug1: identity file /home/test/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-1024
debug1: identity file /home/test/.ssh/id_rsa-cert type -1
debug1: identity file /home/test/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: identity file /home/test/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-4ubuntu4
debug1: match: OpenSSH_5.5p1 Debian-4ubuntu4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-4ubuntu4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr 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 '192.168.1.111' is known and matches the RSA host key.
debug1: Found key in /home/test/.ssh/known_hosts:5
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

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

debug1: An invalid name was supplied

debug1: Next authentication method: publickey
debug1: Offering public key: /home/test/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/test/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: password
test@192.168.1.111's password:

Easy too see: GSSAPI is tried, but fails.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: openssh-server 1:5.5p1-4ubuntu4
ProcVersionSignature: Ubuntu 2.6.35-22.35-server 2.6.35.4
Uname: Linux 2.6.35-22-server x86_64
Architecture: amd64
Date: Mon Nov 15 10:13:10 2010
InstallationMedia: Ubuntu-Server 10.10 "Maverick Meerkat" - Release amd64 (20101007)
ProcEnviron:
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: openssh

[Mathias Gug (mathiaz)]

According to the log file:

keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

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

debug1: An invalid name was supplied

Is there a principal created for 192.168.1.111?

I don't think that using IP addresses is the best option for kerberos.

[Thomas Schweikle (tps)]

First of all, because it makes me angry: WHERE IS A WAY IN LAUNCHPAD TO ACCESS BUGS REPORTED BY ME WITHOUT KNOWING THE BUG ID??????????????????????? Seems missing, was there. I'd really like to have it back! Launchpad is nonsense if I can't access bug reports without knowledge of the URL.

OK. Maybe someone notices it this way!

I've changed setup slightly to make it more convenient with DNS:

192.168.1.24 kvm-test
192.168.1.25 auth
192.168.1.26 UB0001

all names are resolved:
! UB0001:~% host kvm-test
! kvm-test.local has address 192.168.1.24
! UB0001:~% host ub0001
! ub0001.local has address 192.168.1.26
! UB0001:~% host auth
! auth.local has address 192.168.1.25

Principals are created:
! <email address hidden>
! <email address hidden>
! <email address hidden>

Keytab is updated. I've used
! ank -randkey host/kvm-test
! ktadd -k /tmp/krb5.keytab -norandkey host/kvm-test

The generated file /tmp/krb5.keytab was copied to the machine in question.
All fine so far. Logging in to kvm-test succeeds with the krb5-password:
! Linux kvm-test 2.6.35-22-server #35-Ubuntu SMP
! Sat Oct 16 22:02:33 UTC 2010 x86_64 GNU/Linux Ubuntu 10.10
!
! Welcome to the Ubuntu Server!
! * Documentation: http://www.ubuntu.com/server/doc
! Last login: Wed Nov 17 12:38:53 2010 from ub0001.local
! tu@kvm-test:~$ klist
! Ticket cache: FILE:/tmp/krb5cc_2023_AM9554
! Default principal: tu@LOCAL
!
! Valid starting Expires Service principal
! 11/17/10 12:46:29 11/17/10 22:46:29 krbtgt/LOCAL@LOCAL
! renew until 11/18/10 12:46:19

Now since I've got a ticket I might login to auth or ub0001 without authehticating again:
! tu@kvm-test:~$ ssh ub0001
! tu@ub0001's password:

No? Didn't I received a tgt from the krb5-server?
! tu@kvm-test:~$ klist
! Ticket cache: FILE:/tmp/krb5cc_2023_AM9554
! Default principal: tu@LOCAL
!
! Valid starting Expires Service principal
! 11/17/10 12:46:29 11/17/10 22:46:29 krbtgt/LOCAL@LOCAL
! renew until 11/18/10 12:46:19

I did. Not working? OK. Trying rsh.
! UB0001:~% rsh -x kvm-test
! UB0001:~%

Fails without notice. Looks like something realy going wrong. Trying the auth-server all alone:
! UB0001:~% ssh auth
! tu@auth's password:
! Linux auth 2.6.32-25-server #45-Ubuntu SMP
! Sat Oct 16 20:06:58 UTC 2010 x86_64 GNU/Linux Ubuntu 10.04.1 LTS
!
! Welcome to the Ubuntu Server!
! * Documentation: http://www.ubuntu.com/server/doc
!
! Last login: Wed Nov 17 12:41:30 2010 from ub0001.xompu.de
! tu@auth:~$ klist
! Ticket cache: FILE:/tmp/krb5cc_1000_mB3672
! Default principal: tu@LOCAL
!
! Valid starting Expires Service principal
! 11/17/10 12:56:52 11/17/10 22:56:52 krbtgt/LOCAL@LOCAL
! renew until 11/18/10 12:56:52

Looks OK. Now from self to self:
! tu@auth:~$ ssh auth
! tu@auth's password:

The same for rsh, telnet, ... all want, if not failing silently, the password for the user.

[Thomas Schweikle (tps)]

The error seems to be related to "gss_init_sec_context". All host that do not authenticate successful against krb5 breaking after Calling "gss_init_sec_context", while "Delegating credentials". At this moment the connection is closed.

This affects all tools using GSSAPI. I do not think this is a bug with priority "low". It is something that has to be fixed --- it renders Ubuntu unusable in enterprise environments!

[Thomas Schweikle (tps)]

After fixing gss_init_sec_context by installing latest available gss-libraries. The problem is mostly gone.

The remainig problem:

ssh -l tu auth -> password asked
ssh -l tu auth.local -> no password asked

is quite annoying. Digging further down into it.

[Thomas Schweikle (tps)]

The remainig problem is by ssh: the client does not, regardless of setting "GSSAPITrustDNS" to "yes" or "no", correctly canonicalize the given hostname.

[Thomas Schweikle (tps)]

Conclusion:

the handbook shall state:

1. make sure your DNS configuration is correct. It is enough to test on *all* clients:
  - host fqdn
  - host shortname (without domain)
  - host ipaddr
  should handle you the same address and name!

2. make sure your localhost is correct
  - host localhost
  - host 127.0.0.1
  should handle you the same address and name!

3. make sure you entered the fqdn creating credentials.

4. make sure you entered the fqdn exporting keys.

5. while it is recommended to create one key table per service, not all services are configurable where they look for this key table. Some assume "/etc/krb5.keytab" blindly. You'll have to export keys into this one file for these.

6. make sure all parts of kerberos are most actual.

[Thomas Schweikle (tps)]

7. This goes out to the maintainer of the package: make the configuration as minimal as possible. No stuff not necessary (except comments). No useless entries. This is especially true for "/etc/krb5.conf"! It isn't helpful at all having a bloated configuration if you're looking for something like kerberos getting it to work.

Some useful configuration could be:

- snipp -----------------------------------------------------------------------------------------
[libdefaults]
        default_realm = LOCAL

# The following krb5.conf variables are only for MIT Kerberos.
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true

# The following libdefaults parameters are only for Heimdal Kerberos.
        v4_instance_resolve = false
        v4_name_convert = {
                host = {
                        rcmd = host
                        ftp = ftp
                }
                plain = {
                        something = something-else
                }
        }
        fcc-mit-ticketflags = true

[realms]
        LOCAL = {
                kdc = auth.local
                admin_server = auth.local
        }

[domain_realm]
        .local = LOCAL
        local = LOCAL

[login]
        krb4_convert = true
        krb4_get_tickets = false

[logging]
        default = FILE:/var/log/kerberos/krb5lib.log
- snapp -----------------------------------------------------------------------------------------

The domain could be derived from the computers domain while installing. The realm could be the uppercase of this domain.

The original file is, in my humble opinion, worth to be installed into "/usr/share/doc/krb5-config" (or the like).

[Launchpad Janitor (janitor)]

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

[Thomas Schweikle (tps)]

There was a fix for some other ssh related bug, but this fix seems to have fixed this bug too.