Troubleshooting local GSSAPI connections is fairly straight-forward. This page will cover both major Linux distribution sets.
Contents
1. System Preparation
1.1. Installing the Kerberos GSSAPI client and server utility
1.1.1. RedHat, CentOS or Scientific Linux
On RedHat, CentOS or Scientific Linux, install the Kerberos GSSAPI utilities by running the following command (as root):
$ yum install krb5-devel
1.1.2. Debian or Ubuntu
On Debian or Ubuntu, install the Kerberos GSSAPI utilities by running the following command (as root):
$ apt-get install krb5-gss-samples
2. Troubleshooting
To troubleshoot a GSSAPI connection, you require two separate terminals.
2.1. Terminal 1 - As root
In the first terminal, as root, run the following command:
$ gss-server -verbose host@YOUR_HOST_NAME
You should now have the following output with no prompt:
starting...
2.2. Terminal 2 - As your test user
2.2.1. In an X environment
When you launch a terminal from X, e.g. a Gnome or KDE desktop session, the behaviour is different to a pure text environment. This is also the case when you use SSH to connect to a remote server and use display forwarding.
In a second terminal, as your test user, run the following command:
$ gss-client -spnego localhost host@YOUR_HOST_NAME foo
You should now be prompted to select an identity in the the Moonshot Identity Selector. Choose one that will authenticate locally.
2.2.2. In a non-X environment
In a pure command-line environment with no display forwarding available, the Moonshot Identity Selector is not available. Instead, you use the .gss_eap_id file to test your environment.
In the second terminal, as your test user, create the
.gss_eap_idfile in your home directory with the following content:[full NAI of your identity, e.g. steve@YOUR_REALM] [password for the identity]
Then run the following command:
$ gss-client -spnego localhost host@YOUR_HOST_NAME foo
2.3. GSS Output
After selecting your identity, you should now see output in both terminals.
2.3.1. Successful output
In Terminal 1 (as root), the output should scroll rapidly with a lot of hex text before ending with something similar to the following:
: : 73 74 80 00 00 0e 00 00 00 0c 4e fd c8 f7 af 37 18 bc 23 47 6a 5b context flag: GSS_C_MUTUAL_FLAG context flag: GSS_C_REPLAY_FLAG context flag: GSS_C_SEQUENCE_FLAG context flag: GSS_C_CONF_FLAG context flag: GSS_C_INTEG_FLAG Accepted connection using mechanism OID { 1 3 6 1 5 5 15 1 1 17 }. Attribute urn:ietf:params:gss:radius-attribute 79 Authenticated Complete 03070004 Attribute urn:ietf:params:gss:radius-attribute 80 Authenticated Complete 7982a7cd93fbaef973e8d6ccac5e850b Accepted connection: "" Message token (flags=228): 05 04 02 ff 00 00 00 00 00 00 00 00 00 00 00 00 ef 58 6b 46 bd 60 26 d1 c1 4a 58 b0 88 91 49 34 2c 32 fa 93 e7 9d f2 29 e3 f8 09 e6 25 05 12 f2 4e c5 31 71 ba 01 94 8a cb d7 cf 73 05 87 3d Received message: "foo" NOOP tokenIn Terminal 2 (as your test user), the output looks similar to the below (in this example, the hostname is debian7x64.localdomain):
Sending init_sec_context token (size=81)...continue needed... Sending init_sec_context token (size=64)...continue needed... Sending init_sec_context token (size=261)...continue needed... Sending init_sec_context token (size=42)...continue needed... Sending init_sec_context token (size=42)...continue needed... Sending init_sec_context token (size=181)...continue needed... Sending init_sec_context token (size=169)...continue needed... Sending init_sec_context token (size=185)...continue needed... Sending init_sec_context token (size=42)...continue needed... Sending init_sec_context token (size=60)...continue needed... context flag: GSS_C_MUTUAL_FLAG context flag: GSS_C_REPLAY_FLAG context flag: GSS_C_SEQUENCE_FLAG context flag: GSS_C_CONF_FLAG context flag: GSS_C_INTEG_FLAG "steve@debian7x64.localdomain" to "host/debian7x64.localdomain", lifetime -1, flags 13e, locally initiated, open Name type of source name is { 1 2 840 113554 1 2 1 1 }. Mechanism { 1 3 6 1 5 5 2 } supports 4 names 0: { 1 2 840 113554 1 2 1 1 } 1: { 1 2 840 113554 1 2 1 2 } 2: { 1 2 840 113554 1 2 1 3 } 3: { 1 2 840 113554 1 2 1 4 } Signature verified.
2.3.2. Failed output
If the GSSAPI connection failed, you may see one or more errors in either window.
In Terminal 1, you should see one or more messages similar to the below:
reading token flags: 0 bytes read reading token flags: 0 bytes read
In Terminal 2, you should see one or more error messages similar to the below:
GSS-API error initializing context: Unspecified GSS failure. Minor code may provide more information GSS-API error initializing context:
3. Possible solutions
If your GSS connection failed, you will need to diagnose why the error occurred.
3.1. The .gss_eap_id file
A common mistake involves the naming of the .gss_eap_id file.
A simple list command as your test user will allow you to check for it:
$ ls -la ~/.gss_eap_id
If you get a "No such file or directory" error message, double-check that the file exists in the home directory of the user you are running the gss-client command as.
3.2. Directory permissions
Your users need to have access to the /etc/gss directory and its contents. Check that the permissions allow your test user to list and read the contents:
# ls -la /etc/gss total 20 drwxr-xr-x. 2 root root 4096 Jan 20 11:38 . drwxr-xr-x. 117 root root 12288 May 26 11:22 .. -rw-r--r--. 1 root root 90 Jan 20 11:38 mech
# ls -laR /etc/gss /etc/gss: total 0 drwxr-xr-x 3 root root 29 Jan 20 11:38 . drwxr-sr-x 128 root root 580 May 26 11:22 .. -rw-r--r-- 2 root root 39 Jan 20 11:38 mech.d /etc/gss/mech.d: total 1 drwxr-xr-x 2 root root 39 Jan 20 11:38 . drwxr-sr-x 3 root root 29 May 26 11:22 .. -rw-r--r-- 1 root root 258 Jan 20 11:38 moonshot-gss-eap
Still under construction