# Permanent Kerberos with gssproxy and Password Keytab

If there are accounts which run software permanently e.g. used for data collection and shall always be able to write to Kerberos protected network shares, there you may provide the `gssproxy` service with a password keytab.
After Kerberos for NFS and CIFS is handled transparently and there is no need to `kinit`, renew and anything like this because that is handled transparently in the background by `gssproxy` automatically.

!!! warning Attention
    The keytab file is like a cleartext password and needs to be protected!

!!! note
    When the password of the user changes, a new keytab file with the new password needs to be created.

First you need the user name \(\$USER) and the user ID \(\$UID) to prepare the password keytab:

```bash
$ # ensure it does not exist, else it gets extended
$ rm $UID.keytab
$ ktutil
ktutil:  add_entry -password -k 0 -f -p $USER
Password for $USER@D.PSI.CH: 
ktutil:  wkt $UID.keytab
ktutil:  exit
$
```

Note that inside `ktutil` variables are not interpolated as this is not `bash`.
To test if the keytab works as intended do

```bash
$ kinit -t $UID.keytab -k $USER
$
```
and without output it is working fine.

Then as root (`sudo`) make it known to `gssproxy`:

```bash
$ cp $UID.keytab /var/lib/gssproxy/clients/
$ chmod 600 /var/lib/gssproxy/clients/$UID.keytab
$ chown root:root /var/lib/gssproxy/clients/$UID.keytab
```

If you want to [distribute the keytab with Puppet/Hiera](../files/distribute_files), ensure it is [stored in Hiera encrypted](../../puppet/hiera).


!!! hint
    If you have an already working setup and want to e.g. change the service user backing a local user, then you need to create the new keytab accordingly to the above guide.
    But after activation there might still be old tickets in the ticket cache of `gssproxy`.
    So best you then delete the corresponding cache file at `/var/lib/gssproxy/clients/krb5cc_$UID`.