Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Numbered Headings

System Preparation

Installing the Kerberos GSSAPI client and server utility

RedHat, CentOS or Scientific Linux

On RedHat, CentOS or Scientific Linux, install the Kerberos GSSAPI utilities by running the following command (as root):

Code Block
languagebash
$ yum install krb5-devel

Debian or Ubuntu

On Debian or Ubuntu, install the Kerberos GSSAPI utilities by running the following command (as root):

Code Block
languagebash
$ apt-get install krb5-gss-samples

Troubleshooting

To troubleshoot a GSSAPI connection, you require two separate terminal sessions and a RadSec connection to your local Moonshot RP Proxy.

RadSec connection

On a Moonshot client

Moonshot clients do not need to define a RadSec connection (because the service you connect to defines this connection), if you however are trying to troubleshoot the local GSS system, you will need to define this connection to temporarily turn your Moonshot client into a server.

To do this, you need three files from your Moonshot RP Proxy's FreeRADIUS directory: ca.pem, client.pem and client.key.

Store the files in a directory that an ordinary user can read, and check that the files are also readable by an ordinary user. You may wish to rename them to be clearly identifiable.

Also create a /etc/radsec.conf file by following the instructions to configure a Linux Server to connect to an RP Proxy.

Make sure that the file is also readable by an ordinary user.

Tip
After your tests are complete and you are confident that the local GSS system is ok, you can simply delete the four files as they won't be necessary.

On a Moonshot server

As part of configuring your server to connect to an RP Proxy, you will have defined the RadSec connection configuration.

Check the permissions of the four files needed for a RadSec connections:

Code Block
$ cat /etc/radsec.conf
$ cat /location/of/ca.pem
$ cat /location/of/client.pem
$ cat /location/of/client.key

Also check the validity of the certificates used for the connection:

Code Block
$ openssl x509 -enddate -noout -in /location/of/ca.pem
$ openssl x509 -enddate -noout -in /location/of/client.pem

Terminal 1 - As root

  1. In the first terminal, as root, run the following command:

    Code Block
    $ gss-server -verbose host@YOUR_HOST_NAME 
  2. You should now have the following output with no prompt:

    Code Block
    starting...

Terminal 2 - As your test user

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.

  1. In a second terminal, as your test user, run the following command:

    Code Block
    languagepowershell
    $ gss-client -mech {1.3.6.1.5.5.15.1.1.18} localhost host@YOUR_HOST_NAME.FQDN foo
  2. You should now be prompted to select an identity in the Moonshot Identity Selector. Choose one that will authenticate locally.

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.

  1. In the second terminal, as your test user, create the .gss_eap_id file in your home directory with the following content:

    Code Block
    [full NAI of your identity, e.g. steve@YOUR_REALM]
    [password for the identity]
  2. Then run the following command:

    Code Block
    languagepowershell
    $ gss-client -mech {1.3.6.1.5.5.15.1.1.18} localhost host@YOUR_HOST_NAME.FQDN foo

GSS Output

After selecting your identity, you should now see output in both terminals.

Successful output

  1. In Terminal 1 (as root), the output should scroll rapidly with a lot of hex text before ending with something similar to the following:

    Code Block
    :
    :
    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 token
  2. In Terminal 2 (as your test user), the output looks similar to the below (in this example, the hostname is debian7x64.localdomain):

    Code Block
    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.

Failed output

If the GSSAPI connection failed, you may see one or more errors in either window.

  1. In Terminal 1, you should see one or more messages similar to the below:

    Code Block
    reading token flags: 0 bytes read
    reading token flags: 0 bytes read
  2. In Terminal 2, you should see one or more error messages similar to the below:

    Code Block
    GSS-API error initializing context: Unspecified GSS failure.  Minor code may provide more information
    GSS-API error initializing context: 

Possible solutions

If your GSS connection failed, you will need to diagnose why the error occurred.

The .gss_eap_id file

A common mistake involves the naming of the .gss_eap_id file on non-X Moonshot clients.

A simple list command as your test user will allow you to check for it:

Code Block
languagebash
$ 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.

GSS directory permissions

Standard 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:

Code Block
languagebash
titleOn RHEL/CentOS/Scientific Linux
# ls -laR /etc/gss
/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
Code Block
languagebash
titleOn Debian/Ubuntu
$ 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

Hostname

GSS relies on hostnames being correct. Running the hostname and then the hostname -f commands should return the same result:

Code Block
languagebash
$ hostname
debian.localdomain
$ hostname -f
debian.localdomain

If the results are different, you must configure your machine correctly to return the same result.

Either define the name correctly in DNS, or configure the /etc/resolv.conf and /etc/hostname or /etc/sysconfig/network files correctly, or install dnsmasq or a similar utility that will use the /etc/hosts file to correctly resolve your hostname.

Connection

Check that there is no firewall preventing the connection. Often a basic firewall like iptables is installed on the local machine. Check whether you can connect to the Moonshot RP Proxy by trying to connect to port 2083 on the Moonshot RP Proxy over TCP. A "Connection refused" message or a connection timeout is usually a tell-tale sign that something is preventing your connection between your local machine and your Moonshot RP Proxy.

 

Warning

Still under construction