Signs of Triviality

Opinions, mostly my own, on the importance of being and other things.
[homepage] [index] [jschauma@netmeister.org] [@jschauma] [RSS]

Kerberos Error Codes

Trying to debug ssh(1) authenticating using GSSAPIAuthentication against a server, I've run into the following problem:

$ kinit
jschauma@<REALM>'s Password:
$ klist
Credentials cache: API:502:2
        Principal: jschauma@<REALM>

Issued                Expires                 Principal
Feb 14 20:54:49 2013  Feb 15 06:54:49 2013    krbtgt/<REALM>@<REALM>
$ ssh -v -o GSSAPIAuthentication=yes $hostname
[...]
debug1: Next authentication method: gssapi-with-mic
[debug1: Delegating credentials
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
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: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
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

debug1: Next authentication method: publickey
[...]
$ klist
Credentials cache: API:502:2
        Principal: jschauma@<REALM>

Issued                Expires                 Principal
Feb 14 20:54:49 2013  Feb 15 06:54:49 2013    krbtgt/<REALM>@<REALM>
Feb 14 20:55:12 2013  Feb 15 06:54:49 2013    host/<hostname>@<REALM>
$

That is, kerberos authentication does not actually succeed, and the debugging output provided by ssh(1) is less than useful, yet the negotiation appears to have taken place, since I now have the remote hosts credentials in my cache.

So running sshd(8) on the remote host with debugging enabled, I then see:

debug1: userauth-request for user jschauma service ssh-connection method
gssapi-with-mic [preauth]
debug1: attempt 1 failures 0 [preauth]
debug2: input_userauth_request: try method gssapi-with-mic [preauth]
Postponed gssapi-with-mic for jschauma from 172.16.3.10 port 34574 ssh2 [preauth]
debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 230

debug1: Got no client credentials

After much digging around, I finally find that "Unknown code krb5 230" stands for KRB5_KT_KVNONOTFOUND, which in turn has an error message of "Key version number for principal in key table is incorrect". Debugging this issue involved comparing keytabs on the host, the KDC and the KDC master and various rounds of generating new keytabs.

In the process, I've found out that every invocation of kadmin.local -q "ktadd -k outfile host/<hostname>@<REALM> increases the KVNO, but trying to ensure that those are in sync still has not yielded a successful authentication.

However, in the mean time I've tried to figure out how to get the right error message from the GSS minor error code, and to my surprise I was unable to find a simple way. The error codes are defined in the Kerberos distribution in src/lib/krb5/error_tables/krb5_err.et, and they are then generated into what will become /usr/include/krb5/krb5.h on the target system. The mappings in there look like this:

#define KRB5KDC_ERR_NONE                         (-1765328384L)
#define KRB5KDC_ERR_NAME_EXP                     (-1765328383L)
#define KRB5KDC_ERR_SERVICE_EXP                  (-1765328382L)
#define KRB5KDC_ERR_BAD_PVNO                     (-1765328381L)
#define KRB5KDC_ERR_C_OLD_MAST_KVNO              (-1765328380L)
#define KRB5KDC_ERR_S_OLD_MAST_KVNO              (-1765328379L)
#define KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN          (-1765328378L)
#define KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN          (-1765328377L)
[...]

That's right -- if you want to know what "code krb5 230" is, you get to convert that or count errors starting at ERR_NONE until you reach your code. And that doesn't even give you the string representation of the error!

There exist a few tables that map the -1765328384L values to their string representations, but none include a convenient decimal code as the one printed out by sshd(8).

So, if only for my own convenience right now in troubleshooting this issue, here's a table with decimal codes. In the mean time, if you have any suggestions on how to troubleshoot the original problem above, please let me know.

2013-02-13


[Non-trivial command-line fu via @rtfmsh] [Index] [Kerberos v5 Status Codes]