Kerberos Authentication✯

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

Standard Authentication (login/password)✯

To connect to a Kerberized SSH server, simply add <account>@ before 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 it is not possible to use SSH keys 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 - 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 default during the installation of the requirements.

You must enter 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 the school's servers and access certain school services (personal directory on dirs, administrative shares).

This ticket has a limited lifetime, so it must be requested again 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 can do this (as well as libpam-krb5). SSH can only use a ticket already present in the session. Therefore, you must first run kinit with the keytab, then use ssh -K which will use your ticket to authenticate on a Kerberized SSH server.

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 sending of the obtained Kerberos ticket with 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 way, you always have a Kerberos ticket available to connect to ISIMA/LIMOS servers.

In your ~/.bashrc file, add:

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 do not want to display the error message from the kinit command (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 on the ping command. If the domain controller is unreachable (you are not at ISIMA or connected via VPN), the shell opening process will only be slightly delayed (this timeout may cause the ping command to fail 1-2% of the time, but in that case, 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

Retrieving 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✯

On GitLab, in 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 to deploy code on 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 capable of using Kerberos
    - apk update
    - apk del openssh-client-default
    - apk add krb5 openssh-client-krb5

    # Do not check the hostkey of SSH servers
    - mkdir -p ~/.ssh
    - test -f /.dockerenv && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config

    # Retrieve the hexadecimal KEYTAB
    - 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 that 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}