fix some formatting in krb docu

This commit is contained in:
viessm_h 2024-11-21 14:41:12 +01:00
parent 8cf2674d33
commit a7c2d11e95
Signed by: viessm_h
GPG Key ID: 0C24C120CDED56F0

View File

@ -9,56 +9,64 @@ permalink: /merlin7/kerberos.html
--- ---
Projects and users have their own areas in the central PSI AFS service. In order 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. to access to these areas, valid Kerberos and AFS tickets must be granted.
These tickets are automatically granted when accessing through SSH with These tickets are automatically granted when accessing through SSH with
username and password. Alternatively, one can get a granting ticket with the `kinit` (Kerberos) 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. 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 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 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, granting tickets, and their validity can not be extended longer than 7 days. At this point,
one needs to obtain new granting tickets. one needs to obtain new granting tickets.
## Obtaining granting tickets with username and password ## Obtaining granting tickets with username and password
As already described above, the most common use case is to obtain Kerberos and AFS granting tickets As already described above, the most common use case is to obtain Kerberos and AFS granting tickets
by introducing username and password: by introducing username and password:
* When login to Merlin through SSH protocol, if this is done with username + password authentication, * When login to Merlin through SSH protocol, if this is done with username + password authentication,
tickets for Kerberos and AFS will be automatically obtained. 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 * 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). run `kinit` (to obtain a granting Kerberos ticket) followed by `aklog` (to obtain a granting AFS ticket).
See further details below. See further details below.
To manually obtain granting tickets, one has to: 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. 1. To obtain a granting Kerberos ticket, one needs to run `kinit $USER` and enter the PSI password.
```bash
kinit $USER@D.PSI.CH ```bash
``` 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 2. To obtain a granting ticket for AFS, one needs to run `aklog`. No password is necessary, but a valid
Kerberos ticket is mandatory. Kerberos ticket is mandatory.
```bash
aklog
```
3. To list the status of your granted tickets, users can use the `klist` command.
```bash
klist
```
4. To extend the validity of existing granting tickets, users can use the `krenew` command.
```bash
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.
```bash
aklog
```
3. To list the status of your granted tickets, users can use the `klist` command.
```bash
klist
```
4. To extend the validity of existing granting tickets, users can use the `krenew` command.
```bash
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 ## Obtanining granting tickets with keytab
Sometimes, obtaining granting tickets by using password authentication is not possible. An example are user Slurm jobs 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. 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 Be aware that the **keytab** file must be **private**, **fully protected** by correct permissions and not shared with any
other users. other users.
### Creating a keytab file ### Creating a keytab file
@ -66,29 +74,39 @@ other users.
For generating a **keytab**, one has to: For generating a **keytab**, one has to:
1. Load a newer Kerberos ( `krb5/1.20` or higher) from Pmodules: 1. Load a newer Kerberos ( `krb5/1.20` or higher) from Pmodules:
```bash
module load krb5/1.20 ```bash
``` module load krb5/1.20
```
2. Create a private directory for storing the Kerberos **keytab** file 2. Create a private directory for storing the Kerberos **keytab** file
```bash
mkdir -p ~/.k5 ```bash
``` mkdir -p ~/.k5
```
3. Run the `ktutil` utility which comes with the loaded `krb5` Pmodule: 3. Run the `ktutil` utility which comes with the loaded `krb5` Pmodule:
```bash
ktutil ```bash
``` ktutil
```
4. In the `ktutil` console, one has to generate a **keytab** file as follows: 4. In the `ktutil` console, one has to generate a **keytab** file as follows:
```bash
# Replace $USER by your username ```bash
add_entry -password -k 0 -f -p $USER # Replace $USER by your username
wkt /data/user/$USER/.k5/krb5.keytab add_entry -password -k 0 -f -p $USER
exit 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. ```
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: 5. Once back to the main shell, one has to ensure that the file contains the proper permissions:
```bash
chmod 0600 ~/.k5/krb5.keytab ```bash
``` chmod 0600 ~/.k5/krb5.keytab
```
### Obtaining tickets by using keytab files ### Obtaining tickets by using keytab files
@ -106,23 +124,30 @@ Then, from inside the batch script one can obtain granting tickets for Kerberos
The steps should be the following: 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 * 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): (`$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):
```bash
export KRB5CCNAME="$(mktemp "$HOME/.k5/krb5cc_XXXXXX")" ```bash
``` export KRB5CCNAME="$(mktemp "$HOME/.k5/krb5cc_XXXXXX")"
```
* To obtain a Kerberos5 granting ticket, run `kinit` by using your keytab: * To obtain a Kerberos5 granting ticket, run `kinit` by using your keytab:
```bash
kinit -kt "$HOME/.k5/krb5.keytab" $USER@D.PSI.CH ```bash
``` kinit -kt "$HOME/.k5/krb5.keytab" $USER@D.PSI.CH
```
* To obtain a granting AFS ticket, run `aklog`: * To obtain a granting AFS ticket, run `aklog`:
```bash
aklog ```bash
``` aklog
* At the end of the job, you can remove destroy existing Kerberos tickets. ```
```bash
kdestroy * At the end of the job, you can remove destroy existing Kerberos tickets.
```
```bash
kdestroy
```
### Slurm batch script example: obtaining KRB+AFS granting tickets ### Slurm batch script example: obtaining KRB+AFS granting tickets
@ -168,7 +193,6 @@ Then, you can run one or multiple jobs scripts (or parallel job with `srun`). `K
job script or to the parallel job, therefore a single credential cache will be shared amongst different Slurm runs. job script or to the parallel job, therefore a single credential cache will be shared amongst different Slurm runs.
```bash ```bash
#!/bin/bash #!/bin/bash
#SBATCH --partition=hourly # Specify 'general' or 'daily' or 'hourly' #SBATCH --partition=hourly # Specify 'general' or 'daily' or 'hourly'
#SBATCH --time=01:00:00 # Strictly recommended when using 'general' partition. #SBATCH --time=01:00:00 # Strictly recommended when using 'general' partition.