Kerberos Authentication✯

SSH authentication for most workstations, servers, or virtual machines at ISIMA/LIMOS relies on Kerberos, interfaced with our user directory (Active Directory synchronized with the UCA LDAP).

Standard Authentication (login/password)✯

To connect to a Kerberized SSH server, simply prepend <account>@ to the server name.

For example:

ssh vimazeno@vm-etu-vimazeno.local.isima.fr

Kerberos Ticket Authentication (replacing public/private key authentication)✯

Generating a Kerberos ticket is mandatory for each connection, so SSH keys cannot be used for passwordless connections

However, it is possible to generate a keytab to obtain a Kerberos ticket without entering a password.

Kerberized servers

perso
turing
ada
certain student VMs
bastion (this machine requires multi-factor authentication. It also requires an SSH key)

Linux✯

Prerequisites✯

Preconfigure the installation of the krb5-config package:

echo -e "krb5-config krb5-config/default_realm string LOCAL.ISIMA.FR" | sudo debconf-set-selections

or

Enter the Realm name (here: LOCAL.ISIMA.FR - in uppercase) when prompted during the installation of krb5-config:

sudo apt install krb5-user krb5-config

Authentication✯

kinit <uca-account>
# or
kinit <uca-account>@LOCAL.ISIMA.FR # If you use multiple Kerberos realms

The Realm (LOCAL.ISIMA.FR) does not need to be specified if it is set as the default during the installation of the requirements.

You will be prompted for your password.

The klist command lists the user's tickets

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: <uca-account>@LOCAL.ISIMA.FR

Valid starting     Expires            Service principal
08/24/20 10:10:37  08/24/20 20:10:37  krbtgt/LOCAL.ISIMA.FR@LOCAL.ISIMA.FR
        renew until 08/25/20 10:10:37

Here, the user has obtained their Ticket-Granting Ticket (TGT). This will allow them to authenticate with school servers and access certain school services (personal directory on dirs, administrative shares).

This ticket has a limited lifespan and must be renewed when it expires (using kinit).

You can now test an SSH connection using your TGT. You can also force the transfer of the Kerberos ticket to your remote session using the -K option. This is often necessary to access resources from the session you open on the server (e.g., access to a Kerberized NFS share such as your personal directory in ~/shared).

This option may be required if your homedir is directly on the Kerberized NFS share. This is the case for servers like perso.local.isima.fr, turing.local.isima.fr, or ada.local.isima.fr. If you do not forward the TGT to your remote session, you will be allowed to connect to the server but will not have access to your homedir.

ssh -K <uca-account>@perso.local.isima.fr
# Or
ssh -K <uca-account>@turing.local.isima.fr
# Or
ssh -K <uca-account>@ada.local.isima.fr

kdestroy allows you to destroy a ticket. Run this before continuing with the keytab to ensure you obtain a KRB5 ticket with the keytab without entering a password.

Creating the keytab✯

The interactive ktutil command allows you to create a keytab file.

$ ktutil
ktutil:  ?
Available ktutil requests:

clear_list, clear        Clear the current keylist.
read_kt, rkt             Read a krb5 keytab into the current keylist.
read_st, rst             Read a krb4 srvtab into the current keylist.
write_kt, wkt            Write the current keylist to a krb5 keytab.
write_st, wst            Write the current keylist to a krb4 srvtab.
add_entry, addent        Add an entry to the current keylist.
delete_entry, delent     Delete an entry from the current keylist.
list, l                  List the current keylist.
list_requests, lr, ?     List available requests.
quit, exit, q            Exit program.

ktutil:  addent -password -p <uca-account>@LOCAL.ISIMA.FR -k 1 -e aes256-cts-hmac-sha1-96
Password for <uca-account>@LOCAL.ISIMA.FR:
ktutil:  wkt my.keytab
ktutil:  exit

A password-derived secret is generated in the file ~/my.keytab.

Best Practices✯

Similar to your SSH keys, it is prudent to place your keytab (which, remember, is a secret) in a directory with 0700 permissions (owner-only access).

mkdir ~/.krb5
chmod 0700 ~/.krb5
mv my.keytab ~/.krb5

Authentication with Keytab (passwordless)✯

Notes

It is not possible to configure SSH to retrieve the ticket from the KDC/AD; only the kinit command (and libpam-krb5) can do this. SSH can only use a ticket already present in the session. You must first run kinit with the keytab, then use ssh -K to authenticate to a Kerberized SSH server using your ticket.

This keytab allows you to obtain a KDC/AD ticket without entering your password.

$ kinit -k -t ~/.krb5/my.keytab <uca-account>@LOCAL.ISIMA.FR
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: <uca-account>@LOCAL.ISIMA.FR

Valid starting     Expires            Service principal
08/24/20 10:31:13  08/24/20 20:31:13  krbtgt/LOCAL.ISIMA.FR@LOCAL.ISIMA.FR
        renew until 08/25/20 10:31:13

You can test the connection by forcing the Kerberos ticket to be sent using the -K option:

ssh -K <uca-account>@perso.local.isima.fr
# Or
ssh -K <uca-account>@turing.local.isima.fr
# Or
ssh -K <uca-account>@ada.local.isima.fr

It may be useful to obtain a Kerberos ticket via kinit from your .bashrc. This ensures you always have a Kerberos ticket available to connect to ISIMA/LIMOS servers.

Add the following to your ~/.bashrc file:

if timeout 0.4 ping -c1 192.168.100.75 > /dev/null 2>&1; then
  if ! klist -s; then
      kinit -k -t ~/.krb5/my.keytab <uca-account>@LOCAL.ISIMA.FR 2> /dev/null
      true
  fi
fi

If you do not already have a KRB5 ticket, one will be requested from the domain controller. We suppress the kinit error message (2> /dev/null) because if you are not at ISIMA, you will always receive an error when opening a terminal.

I have set a 0.4-second timeout for the ping command. If the domain controller is unreachable (you are not at ISIMA or connected via VPN), this process will only slightly delay shell startup (this timeout may cause the ping command to fail 1-2% of the time, but the ticket can still be obtained by running the kinit command as described above).

Windows✯

Mac✯

CI / GitLab✯

Exporting the keytab in hexadecimal✯

hexdump -v -e '1/1 "%02x"'  ~/.krb5/my.keytab > ~/.krb5/my.keytab.hex

Recovering the keytab from its hexadecimal version✯

To be used in CI/CD:

sed 's/\([0-9A-F]\{2\}\)/\\\\\\x\1/gI'  ~/.krb5/my.keytab.hex | xargs printf

GitLab CI variable✯

In GitLab, go to CI/CD > Variables [collapse] > create the following entry:

Key: KEYTAB
Value: (the contents of the file ~/.krb5/my.keytab.hex)

Example .gitlab-ci.yml file for deploying code to a remote server using rsync and a Kerberos keytab✯

The build and test stages are not shown in this example; only the deployment using Kerberos is demonstrated.

You can add stages using other Docker images to build your project and use the stage below to deploy the code to the remote server.

stages:
  - deploy

production:
  stage: deploy
  image: instrumentisto/rsync-ssh:latest
  script:

    # Install Kerberos in the Docker container and replace the default SSH client with one that supports Kerberos
    - apk update
    - apk del openssh-client-default
    - apk add krb5 openssh-client-krb5

    # Do not verify SSH host keys
    - mkdir -p ~/.ssh
    - test -f /.dockerenv && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config

    # Retrieve the keytab in hexadecimal
    - echo "${KEYTAB}" > my.keytab.hex

    # Convert the keytab to binary
    - sed 's/\([0-9A-F]\{2\}\)/\\\\\\x\1/gI' my.keytab.hex | xargs printf > my.keytab

    # Request a Kerberos ticket using the keytab
    - kinit -k -t my.keytab ${USERNAME}@LOCAL.ISIMA.FR

    # Verify the Kerberos ticket was obtained
    - klist

    # Deploy the code
    - rsync -az -e "ssh -K" ${DIRS_AND_FILES_TO_COPY} ${USERNAME}@${REMOTE_HOST_FQDN}:${REMOTE_LOCATION}