Linux @ CERN

CERN > IT > Linux

Accessing CERN Linux machines via Kerberos

Kerberos is shared-secret networked authentication system. Its use at CERN serves a dual purpose:


In the past both Kerberos version IV and 5 were supported: Kerberos IV support has been stopped in 2010.
: This document does not aim to explain Kerberos. For an overview and introduction into the concepts, please see man kerberos, MIT's site or the Kerberos FAQ. Several books exist on the subject as well.

Client-side configuration

In order for Kerberos to work, the user needs to be registered in a central database (KDC). In CERN parlance, this means a CERN account is required for the user.

Kerberos client binaries are part of the default install of many operating systems (such as Mac OS-X, BSD, Linux, Solaris, ..), or are at least available as add-ons. This document does not cover how to install these binaries on a particular operating system.

Linux clients must be registered with "LINUX" as the "Operating System" in the network database (go to https://network.cern.ch to check the registration). The precise "Version" of the "Operating System" does not matter for this purpose.

Trying it out

To test whether a client is configured correctly, please use kinit and klist. These commands should live in your default PATH, otherwise look into /usr/kerberos/bin or /usr/heimdal/bin (please avoid using kinit from a Java JRE, these often have problems such as echoing the password). 

$ kinit afsusername@CERN.CH
afsusername@CERN.CH's Password: <enter your password>
$
In order to verify that everything went fine, use klist: 
$ klist
Credentials cache: FILE:/tmp/krb5cc_USERID_somenumber
        Principal: afsusername@CERN.CH

  Issued           Expires          Principal
Sep 28 15:20:24  Sep 29 16:20:23  krbtgt/CERN.CH@CERN.CH
Sep 28 15:20:24  Sep 29 16:20:23  afs@CERN.CH

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
In this example, only Kerberos 5 credentials for the CERN realm were obtained as Kerberos 4 is no longer supported, and the expiry time is in the future (at the time of this writing). Looks good.

In order to get access to AFS after a successful authentication, you will need to get a "forwardable" TGT, and instruct your ssh client to actually transfer it over to the server (who will then use it to obtain an AFS token for your session). Use klist -f to check whether your TGT is "forwardable" - usually it then has a flag "F": 

  Issued           Expires        Flags    Principal 
Sep 29 13:24:41  Sep 30 13:24:03  FPR   krbtgt/CERN.CH@CERN.CH

To continue testing, use ssh -v afsusername@hostname.cern.ch klist -f\; tokens\; touch .sshtest (this should log you in, show your credentials - both Kerberos and AFS, and try to actually write something into your AFS home directory) - if all succeeds, you are set to use passwordless Kerberos. If you get error messages from these commands or are being asked for your passwords, the "verbose" output should allow you to pinpoint what went wrong. You may need to explicitly set some of the ssh client options.

Client configuration - Kerberos

In order to use CERN authentication, the name of the CERN KDC(s) need to be specified explicitly.

To get this done, a working config file (with CERN as default realm) can be copied from here. Default location for this configuration file is /etc/krb5.conf on most Linuxes and Mac OS X (here Library/Preferences/edu.mit.Kerberos would work as well), on some systems (Solaris) it is in /etc/krb5/.

You can edit the krb5.conf file using the following syntax, which is accepted by both the MIT and Heimdal Kerberos implementations.

As an alternative to editing the krb5.conf directly, the below information can typically also be entered via any Kerberos-configuring user interface your vendor may provide. If you do not have "root" privileges on the client machine, you can instruct MIT Kerberos to look at a different file by setting the KRB5_CONFIG environment variable. 

[realms]
; AD  : This Kerberos configuration is for CERN's Active Directory realm.
[libdefaults]
 default_realm = CERN.CH
 ticket_lifetime = 25h
 renew_lifetime = 120h
 forwardable = true
 proxiable = true
 ;Next two lines MAY be needed - depending on Kerberos implementation, 
 ;do not uncomment unless you see preauthentication errors on your client. 
 ;default_tkt_enctypes = arcfour-hmac-md5 aes256-cts aes128-cts des3-cbc-sha1 des-cbc-md5 des-cbc-crc
 ;allow_weak_crypto = true
...
[realms]
...
 CERN.CH = {
  default_domain = cern.ch
  kdc = cerndc.cern.ch
}
...
[domain_realm]
...
 .cern.ch = CERN.CH
...

Once you can get TGTs from the CERN realm as described above, the client-side Kerberos configuration is assumed to work.

Client configuration - SSH

Two flavours of the SSH protocol exist, which support Kerberos differently:

A common implementation of these protocols is found in OpenSSH, widely used in the Linux world, and also part of CERN Linux distributions.

ssh clients may need some help to try Kerberos for authentication. The following options should be enabled (via the command line or in ~/.ssh/config, see man ssh_config):

The command-line switch "-v" (verbose) usually is very helpful - you should see messages mentioning Kerberos/AFS/GSSAPI (the following examples are from different sessions): 
debug1: Trying Kerberos v5 authentication.
debug1: Kerberos v5 authentication accepted.
debug1: Kerberos v4 authentication accepted.
debug1: Kerberos v4 challenge successful.
debug1: Kerberos v4 TGT forwarded (afsaccount@CERN.CH).
debug1: AFS token for cell cern.ch forwarded.
debug1: Next authentication method: gssapi-with-mic
debug1: Delegating credentials
debug1: Authentication succeeded (gssapi-with-mic).

Some common SSH errors:

Client configuration - other applications

It is possible to use Kerberos for local authentication (this is how CERN Linux machines are generally set up). However, such a setup only makes sense on machines that are permanently connected to the network, and have permanent connectivity to the CERN KDCs. In such cases, TGTs are typically obtained directly on login and get renewed via screensavers. For CERN Linux machines, a variant of Red Hat's pam_krb5 is being used to achieve this.

Besides SSH, other network services can also be made Kerberos-aware. Examples including web services (via the SPNEGO/GSSAPI authentication mechanism), ORACLE or CERN tools such as the Quattor CDB client.

Server-side configuration and troubleshooting

Kerberos is a shared-secret authentication system. This implies that both the users and the machines need to be registered at a central place, the KDC. These shared secrets are versioned, and both the machine and the KDC need to be using the same version of the secret. Most CERN Linux machines should get registered at install time, but in case of authentication problems the following may help to troubleshoot.

msktutil: acquiring keytab file on unsupported linux system.

Note:For CERN supported Linux systems please always use cern-get-keytab utility.
In order to acquire keytab from CERN KDC msktutil version 0.4.2 (or newer) is needed. It may be included in your Linux distribution, if not, sources are available from msktutil site.

Obtaining initial keytab using msktutil

Keytab recreation/acquiring additional service principal names using msktutil

Once initial keytab has been created (and is still valid) it can be regenerated using msktutil: Additional service principal names (for example used for implementing http server kerberos authentication) / keys can be obtained also using msktutil: