Not only have I been playing with Kerberos, but I’ve also been playing with IPv6. So, naturally, kerberos over IPv6 was a test I had to do.
Now because I’m only playing with IPv6 I’ve been using different DNS names; so kdc.spuddy.org is on IPv4 but kdc.ip6.spuddy.org is on IPv6.
So, test!
$ telnet -a -f kdc.ip6.spuddy.org
Trying 2001:470:1f07:dc4:3c46:1aff:fef4:d7a3...
Connected to kdc.ip6.spuddy.org (2001:470:1f07:dc4:3c46:1aff:fef4:d7a3).
Escape character is '^]'.
[ Kerberos V5 accepts you as ``sweh@SPUDDY.ORG'' ]
[ Kerberos V5 accepted forwarded credentials ]
Last login: Sat Jul 9 07:48:04 from kclient.spuddy.org
[sweh@kdc ~]$
Perfect!
But SSH…
[sweh@kclient ~]$ ssh -o 'GSSAPIDelegateCredentials=yes' kdc.ip6.spuddy.org
sweh@kdc.ip6.spuddy.org's password:
Ugh. It’s asking for a password, so the ticket wasn’t accepted. Ugh.
To debug it, I ran “sshd -d -p 2222” and tried connecting to that. This showed in the debug output…
debug1: userauth-request for user sweh service ssh-connection method gssapi-with-mic
debug1: attempt 1 failures 1
Postponed gssapi-with-mic for sweh from 2001:470:1f07:dc4:1c79:45ff:fe48:1534 port 58243 ssh2
debug1: Unspecified GSS failure. Minor code may provide more information
Wrong principal in request
Wrong principal. Doesn’t sound good! I’d already ensured that the keytab had both ip4 and ip6 principals in it (“klist -k”).
Googling around makes me think this is a problem with older versions of OpenSSH. eg http://mailman.mit.edu/pipermail/kerberos/2007-January/011126.html
But now it appears the solution is upgrading to OpenSSH 4.5p1 along with the associated GSSAPI Key Exchange patch. The 4.5p1 GSSKEX patch supports a new config option (introduced in 4.4p1) “GSSAPIStrictAcceptorCheck=no” which, according to the man page:
If ‘no’ then the client may authenticate against any service key stored in the machine’s default store. This facility is provided to assist with operation on multi home machines
Huh, so if I make /etc/hosts on kclient have the IPv6 address associated with the kdc… it worked! So it seems the name the ssh client tries to connect to impacts whether the remote sshd accepts the ticket or not. Odd. This’d impact anyone with CNAMEs or multiple A records or… The “acceptor check” flag lets sshd check against any principal in the keytab, not just the first.
Of course, RedHat is “long term release” and it doesn’t look like this enhancement has been backported to RHEL5.
A little annoying!