Trying to debug ssh(1) authenticating using GSSAPIAuthentication against a server, I've run into the following problem:
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:
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:
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.