gitea-pages/pages/merlin7/02-How-To-Use-Merlin/kerberos.md

title, keywords, last_updated, summary, sidebar, permalink

title	keywords	last_updated	summary	sidebar	permalink
Kerberos and AFS authentication	kerberos, AFS, kinit, klist, keytab, tickets, connecting, client, configuration, slurm	07 September 2022	This document describes how to use Kerberos.	merlin7_sidebar	/merlin7/kerberos.html

Projects and users have their own areas in the central PSI AFS service. In order to access to these areas, valid Kerberos and AFS tickets must be granted.

These tickets are automatically granted when accessing through SSH with username and password. Alternatively, one can get a granting ticket with the kinit (Kerberos) and aklog (AFS ticket, which needs to be run after kinit) commands.

Due to PSI security policies, the maximum lifetime of the ticket is 7 days, and the default time is 10 hours. It means than one needs to constantly renew (krenew command) the existing granting tickets, and their validity can not be extended longer than 7 days. At this point, one needs to obtain new granting tickets.

Obtaining granting tickets with username and password

As already described above, the most common use case is to obtain Kerberos and AFS granting tickets by introducing username and password:

• When login to Merlin through SSH protocol, if this is done with username + password authentication, tickets for Kerberos and AFS will be automatically obtained.
• When login to Merlin through NoMachine, no Kerberos and AFS are granted. Therefore, users need to run kinit (to obtain a granting Kerberos ticket) followed by aklog (to obtain a granting AFS ticket). See further details below.

To manually obtain granting tickets, one has to:

1. To obtain a granting Kerberos ticket, one needs to run kinit $USER and enter the PSI password.

   kinit $USER@D.PSI.CH
   

2. To obtain a granting ticket for AFS, one needs to run aklog. No password is necessary, but a valid Kerberos ticket is mandatory.

   aklog
   

3. To list the status of your granted tickets, users can use the klist command.

   klist
   

4. To extend the validity of existing granting tickets, users can use the krenew command.

   krenew
   

   • Keep in mind that the maximum lifetime for granting tickets is 7 days, therefore krenew can not be used beyond that limit, and then kinit should be used instead.

Obtanining granting tickets with keytab

Sometimes, obtaining granting tickets by using password authentication is not possible. An example are user Slurm jobs requiring access to private areas in AFS. For that, there's the possibility to generate a keytab file.

Be aware that the keytab file must be private, fully protected by correct permissions and not shared with any other users.

Creating a keytab file

For generating a keytab, one has to:

1. Load a newer Kerberos ( krb5/1.20 or higher) from Pmodules:

   module load krb5/1.20
   

2. Create a private directory for storing the Kerberos keytab file

   mkdir -p ~/.k5
   

3. Run the ktutil utility which comes with the loaded krb5 Pmodule:

   ktutil
   

4. In the ktutil console, one has to generate a keytab file as follows:

   # Replace $USER by your username
   add_entry -password -k 0 -f -p $USER
   wkt /data/user/$USER/.k5/krb5.keytab
   exit
   

   Notice that you will need to add your password once. This step is required for generating the keytab file.

5. Once back to the main shell, one has to ensure that the file contains the proper permissions:

   chmod 0600 ~/.k5/krb5.keytab
   

Obtaining tickets by using keytab files

Once the keytab is created, one can obtain kerberos tickets without being prompted for a password as follows:

kinit -kt ~/.k5/krb5.keytab $USER
aklog

Slurm jobs accessing AFS

Some jobs may require to access private areas in AFS. For that, having a valid keytab file is required. Then, from inside the batch script one can obtain granting tickets for Kerberos and AFS, which can be used for accessing AFS private areas.

The steps should be the following:

• Setup KRB5CCNAME, which can be used to specify the location of the Kerberos5 credentials (ticket) cache. In general it should point to a shared area ($HOME/.k5 is a good location), and is strongly recommended to generate an independent Kerberos5 credential cache (it is, creating a new credential cache per Slurm job):

  export KRB5CCNAME="$(mktemp "$HOME/.k5/krb5cc_XXXXXX")"
  

• To obtain a Kerberos5 granting ticket, run kinit by using your keytab:

  kinit -kt "$HOME/.k5/krb5.keytab" $USER@D.PSI.CH
  

• To obtain a granting AFS ticket, run aklog:

  aklog
  

• At the end of the job, you can remove destroy existing Kerberos tickets.

  kdestroy
  

Slurm batch script example: obtaining KRB+AFS granting tickets

Example 1: Independent crendetial cache per Slurm job

This is the recommended way. At the end of the job, is strongly recommended to remove / destroy the existing kerberos tickets.

#!/bin/bash
#SBATCH --partition=hourly            # Specify 'general' or 'daily' or 'hourly'
#SBATCH --time=01:00:00               # Strictly recommended when using 'general' partition.
#SBATCH --output=run.out              # Generate custom output file
#SBATCH --error=run.err               # Generate custom error  file
#SBATCH --nodes=1                     # Uncomment and specify #nodes to use
#SBATCH --ntasks=1                    # Uncomment and specify #nodes to use 
#SBATCH --cpus-per-task=1
#SBATCH --constraint=xeon-gold-6152
#SBATCH --hint=nomultithread
#SBATCH --job-name=krb5

export KRB5CCNAME="$(mktemp "$HOME/.k5/krb5cc_XXXXXX")"
kinit -kt "$HOME/.k5/krb5.keytab" $USER@D.PSI.CH
aklog
klist

echo "Here should go my batch script code."

# Destroy Kerberos tickets created for this job only
kdestroy
klist

Example 2: Shared credential cache

Some users may need/prefer to run with a shared cache file. For doing that, one needs to setup KRB5CCNAME from the login node session, before submitting the job.

export KRB5CCNAME="$(mktemp "$HOME/.k5/krb5cc_XXXXXX")"

Then, you can run one or multiple jobs scripts (or parallel job with srun). KRB5CCNAME will be propagated to the job script or to the parallel job, therefore a single credential cache will be shared amongst different Slurm runs.

#!/bin/bash
#SBATCH --partition=hourly            # Specify 'general' or 'daily' or 'hourly'
#SBATCH --time=01:00:00               # Strictly recommended when using 'general' partition.
#SBATCH --output=run.out              # Generate custom output file
#SBATCH --error=run.err               # Generate custom error  file
#SBATCH --nodes=1                     # Uncomment and specify #nodes to use
#SBATCH --ntasks=1                    # Uncomment and specify #nodes to use 
#SBATCH --cpus-per-task=1
#SBATCH --constraint=xeon-gold-6152
#SBATCH --hint=nomultithread
#SBATCH --job-name=krb5

# KRB5CCNAME is inherit from the login node session
kinit -kt "$HOME/.k5/krb5.keytab" $USER@D.PSI.CH
aklog
klist

echo "Here should go my batch script code."

echo "No need to run 'kdestroy', as it may have to survive for running other jobs"