Getting SSH to work consistently well with Kerberos seems to run into one thing consistently: problems. It does work, but when it doesn't the messages are not helpful and only one's imagination and persistence remains. The documentation is not great in this area and searching the internet for clues results in slim pickings. Here's the latest problem:


After rebooting a system, ssh using Kerberos/gssapi no longer worked. The configuration had not changed, but off I went to hunt it down.


This is the ssh client side debug output:

debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1:  An invalid name was supplied
unknown mech-code 0 for mech 1 2 752 43 14 2

debug1:  Miscellaneous failure (see text)
unknown mech-code 0 for mech 1 3 6 1 5 5 14

debug1:  Miscellaneous failure (see text)
unknown mech-code 2 for mech 1 3 6 1 4 1 311 2 2 10

debug1:  An unsupported mechanism was requested
unknown mech-code 0 for mech 1 3 5 1 5 2 7

debug1:  Miscellaneous failure (see text)
unknown mech-code 0 for mech 1 3 6 1 5 2 5

Some of these OIDs can be easily decoded using OID Repository, such as:

  • 1 3 6 1 5 5 14
    • {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) scramsha1(14)}
  • 1 3 6 1 5 2 5
    • {iso(1) identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) iakerb(5)}

But that's a wild goose chase and is merely interesting. The critical clue is An invalid name was supplied. Sadly it doesn't say what name was invalid.

On the server side, there's error text of:

debug1:  No credentials were supplied, or the credentials were unavailable or inaccessible.
unknown mech-code 0 for mech { 1 2 840 113554 1 2 2 }

That oid is just {iso(1) member-body(2) us(840) mit(113554) infosys(1) gssapi(2) krb5(2)}, meaning it's trying to do krb5 via gssapi. Again, the important clue is the prior line, which is even less helpful than the client side.

There are only two names of interest in a krb5 interaction, assuming the realms are set properly: the principle name of the user and the service principle name (SPN). I'm sure that my tickets are correct because they work for other things. The SPN is the only possible thing that could be amiss.

I did find this page about principles that gave me a hint. That little section at the end, SSH advice and that one option, GSSAPIStrictAcceptorCheck. The default is yes, so I did what it said and tried no, then viola, ssh worked.

Now the question is why? That page is specific about the name that gethostname() returns. That's a library call that returns the same string as the command hostname. So I did this:

# ktutil list | grep $(hostname)
#

and got NOTHING. So I tried this:

ktutil list | grep -i $(hostname)
  2  aes256-cts-hmac-sha1-96 HOST/SRV.example.com@DOMAIN.EXAMPLE.COM
...
#

And got a bunch of HOST entries. Uhg, are they really case sensitive, I'm sad. I'm using AD, so I ran this:

# net ads keytab add host/$(hostname)
Processing principals to add...

This creates keytab entries that are the same case as the hostname. Also important to know is that the case of host matters too! SSH looks for host/servername so make sure of that as well. Then you can GSSAPIStrictAcceptorCheck back to yes, or remove the config line since that's probably the default for your sshd if it's recent.