At this point I have what seems to be a working KDC running on setback host, so it is not time to start configuring client on the KDC and on other Linux devices about the network.

Goals

  1. Local logon to setback will acquire user principal ticket fomr KDC, and Kerberos will be the preferred authentication method for connecting to ssh server on setback.
  2. Local logon to velma will auacquire user principal ticket from KDC, and Kerberos will be the prefered authentication method for ssh on velma.
  3. Local logon to bakerstreet will acquire user principas ticket from KDC, and Kerberos will be the preferred authentication method for ssh on bakerstreet.

Prerequisites

Working Network Time Protocol (NTP)

Validate NTP is working on systems using systemd by issuing timedatectl status command. Using salt to survey the three clients I am interested in for this effort:

  $ sudo salt -L setback.grimmig.mine.nu,velma.grimmig.mine.nu,bakerstreet.grimmig.mine.nu cmd.run 'timedatectl status'
velma.grimmig.mine.nu:
                   Local time: Tue 2019-10-29 10:06:13 CDT
               Universal time: Tue 2019-10-29 15:06:13 UTC
                     RTC time: n/a
                    Time zone: US/Central (CDT, -0500)
    System clock synchronized: no
                  NTP service: inactive
              RTC in local TZ: no
setback.grimmig.mine.nu:
                   Local time: Tue 2019-10-29 10:06:15 CDT
               Universal time: Tue 2019-10-29 15:06:15 UTC
                     RTC time: Tue 2019-10-29 15:06:15
                    Time zone: US/Central (CDT, -0500)
    System clock synchronized: yes
                  NTP service: active
              RTC in local TZ: no
bakerstreet.grimmig.mine.nu:
                   Local time: Tue 2019-10-29 10:10:33 CDT
               Universal time: Tue 2019-10-29 15:10:33 UTC
                     RTC time: Tue 2019-10-29 15:10:33
                    Time zone: America/Chicago (CDT, -0500)
    System clock synchronized: no
                  NTP service: inactive
              RTC in local TZ: no

So neither velma nor bakerstreet are currently using NTP, so let’s fix that first, again using salt:

$ sudo salt -L velma.grimmig.mine.nu,bakerstreet.grimmig.mine.nu cmd.run 'timedatectl set-ntp true && systemctl restart systemd-timedated'
velma.grimmig.mine.nu:
bakerstreet.grimmig.mine.nu:

And one more check with salt to confirm all are running NTP service and are syncing time:

chuck@setback ~ $ sudo salt -L setback.grimmig.mine.nu,velma.grimmig.mine.nu,bakerstreet.grimmig.mine.nu cmd.run 'timedatectl status'
velma.grimmig.mine.nu:
                   Local time: Tue 2019-10-29 10:24:09 CDT
               Universal time: Tue 2019-10-29 15:24:09 UTC
                     RTC time: n/a
                    Time zone: US/Central (CDT, -0500)
    System clock synchronized: yes
                  NTP service: active
              RTC in local TZ: no
setback.grimmig.mine.nu:
                   Local time: Tue 2019-10-29 10:24:09 CDT
               Universal time: Tue 2019-10-29 15:24:09 UTC
                     RTC time: Tue 2019-10-29 15:24:09
                    Time zone: US/Central (CDT, -0500)
    System clock synchronized: yes
                  NTP service: active
              RTC in local TZ: no
bakerstreet.grimmig.mine.nu:
                   Local time: Tue 2019-10-29 10:24:10 CDT
               Universal time: Tue 2019-10-29 15:24:10 UTC
                     RTC time: Tue 2019-10-29 15:24:10
                    Time zone: America/Chicago (CDT, -0500)
    System clock synchronized: yes
                  NTP service: active
              RTC in local TZ: no

OK, now that they all look good, let’s just check the services for any issues reaching the time servers, again using salt we run systemctl status systemd-timesyncd.service command to check the service on each device:

$ sudo salt -L setback.grimmig.mine.nu,velma.grimmig.mine.nu,bakerstreet.grimmig.mine.nu cmd.run 'systemctl status systemd-timesyncd.service'
bakerstreet.grimmig.mine.nu:
    * systemd-timesyncd.service - Network Time Synchronization
       Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
       Active: active (running) since Tue 2019-10-29 10:27:03 CDT; 8min ago
         Docs: man:systemd-timesyncd.service(8)
     Main PID: 609560 (systemd-timesyn)
       Status: "Synchronized to time server for the first time 206.108.0.131:123 (0.gentoo.pool.ntp.org)."
          CPU: 1.451s
       CGroup: /system.slice/systemd-timesyncd.service
               `-609560 /lib/systemd/systemd-timesyncd

    Oct 29 10:27:02 bakerstreet systemd[1]: Starting Network Time Synchronization...
    Oct 29 10:27:03 bakerstreet systemd[1]: Started Network Time Synchronization.
    Oct 29 10:22:47 bakerstreet systemd-timesyncd[609560]: Synchronized to time server for the first time 206.108.0.131:123 (0.gentoo.pool.ntp.org).

setback.grimmig.mine.nu:
    * systemd-timesyncd.service - Network Time Synchronization
       Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
       Active: active (running) since Sat 2019-10-26 15:31:48 CDT; 2 days ago
         Docs: man:systemd-timesyncd.service(8)
     Main PID: 2293 (systemd-timesyn)
       Status: "Synchronized to time server for the first time 184.105.182.7:123 (0.gentoo.pool.ntp.org)."
        Tasks: 2
       Memory: 1.6M
          CPU: 669ms
       CGroup: /system.slice/systemd-timesyncd.service
               `-2293 /lib/systemd/systemd-timesyncd

    Oct 26 15:31:48 setback systemd[1]: Starting Network Time Synchronization...
    Oct 26 15:31:48 setback systemd[1]: Started Network Time Synchronization.
    Oct 26 15:32:15 setback systemd-timesyncd[2293]: Network configuration changed, trying to establish connection.
    Oct 26 15:32:55 setback systemd-timesyncd[2293]: Synchronized to time server for the first time 184.105.182.7:123 (0.gentoo.pool.ntp.org).

velma.grimmig.mine.nu:
    * systemd-timesyncd.service - Network Time Synchronization
       Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
       Active: active (running) since Tue 2019-10-29 10:22:42 CDT; 12min ago
         Docs: man:systemd-timesyncd.service(8)
     Main PID: 207021 (systemd-timesyn)
       Status: "Synchronized to time server for the first time 206.108.0.131:123 (0.gentoo.pool.ntp.org)."
          CPU: 284ms
       CGroup: /system.slice/systemd-timesyncd.service
               `-207021 /lib/systemd/systemd-timesyncd

    Oct 29 10:22:42 velma systemd[1]: Starting Network Time Synchronization...
    Oct 29 10:22:42 velma systemd[1]: Started Network Time Synchronization.
    Oct 29 10:22:44 velma systemd-timesyncd[207021]: Synchronized to time server for the first time 206.108.0.131:123 (0.gentoo.pool.ntp.org).

OK, again, everything is looking good, so time to move on.

Working Domain Name Service (DNS)

Kerberos ticketing depends on working which I will define for this post as the forward and reverse lookups work for the KDC. Further the hostname -f command returns the fully qualified domain name for the KDC. The same expectations will need to be in place for devices hoping to make use of the KDC.

$ sudo salt -L setback.grimmig.mine.nu,velma.grimmig.mine.nu,bakerstreet.grimmig.mine.nu cmd.run \
'dig +noall +answer $(hostname -f) && IP=`dig +short $(hostname -f)`;dig +noall +answer -x $IP'
bakerstreet.grimmig.mine.nu:
    localhost.		655360	IN	A	127.0.0.1
setback.grimmig.mine.nu:
    setback.grimmig.mine.nu. 77391	IN	A	192.168.100.96
    96.100.168.192.in-addr.arpa. 77391 IN	PTR	setback.grimmig.mine.nu.
velma.grimmig.mine.nu:
    velma.grimmig.mine.nu.	66795	IN	A	192.168.100.238

OK, well that is somewhat less than ideal, DNS problems for bakerstreet and velma, #sad. After a bit of investigation and cleanup of /etc/hosts files on velma and bakerstreet and it’s time to check again:

$ sudo salt -L setback.grimmig.mine.nu,velma.grimmig.mine.nu,bakerstreet.grimmig.mine.nu cmd.run 'dig +noall +answer $(hostname -f) && IP=`dig +short $(hostname -f)`;dig +noall +answer -x $IP'
setback.grimmig.mine.nu:
    setback.grimmig.mine.nu. 73711	IN	A	192.168.100.96
    96.100.168.192.in-addr.arpa. 73711 IN	PTR	setback.grimmig.mine.nu.

bakerstreet.grimmig.mine.nu:
    bakerstreet.grimmig.mine.nu. 63110 IN	A	192.168.100.55
    55.100.168.192.in-addr.arpa. 63111 IN	PTR	bakerstreet.grimmig.mine.nu.

velma.grimmig.mine.nu:
    velma.grimmig.mine.nu.	63115	IN	A	192.168.100.238
    238.100.168.192.in-addr.arpa. 86400 IN	PTR	velma.grimmig.mine.nu.

At last both time and DNS are looking consistent accross the three machines.

Configuration

For this initial set up I will be using the following:

SERVER

  • DNS domain: grimmig.mine.nu
  • Kerberos realm: GRIMMIG.MINE.NU
  • Key Distribution Center (KDC) host: setback.grimmig.mine.nu
  • KDC config file: /var/lib/krb5kdc/kdc.conf
  • Keytab file: /etc/krb5.keytab
  • Admin ACL file: /var/lib/krb5kdc/kadm5.acl
  • Readable only by root

CLIENT

  • Client configuration file: /etc/krb5.conf
  • PAM file to allow Kerberos system access: /etc/pam.d/system-auth
  • Keytab file: /etc/krb5.keytab

    Steps

  • Install necessary packages on machines:
    • app-crypt/mit-krb5-1.17-r1
    • sys-auth/pam_krb5-4.7
    • sys-auth/pambase (USE flags enabled “cracklib nullok pam_krb5 sha512 systemd”)
  • With the packages installed, copy krb5.conf and krb5.keytab to the machines using salt:
  • setback is the kdc, and is source of keytab and config file, so no need to copy to it.
$ sudo salt -L bakerstreet.grimmig.mine.nu,velma.grimmig.mine.nu state.apply kerberos
velma.grimmig.mine.nu:
----------
          ID: /etc/krb5.keytab
    Function: file.managed
      Result: True
     Comment: File /etc/krb5.keytab is in the correct state
     Started: 15:55:52.344900
    Duration: 125.49 ms
     Changes:   
----------
          ID: /etc/krb5.conf
    Function: file.managed
      Result: True
     Comment: File /etc/krb5.conf is in the correct state
     Started: 15:55:52.470567
    Duration: 84.123 ms
     Changes:   

Summary for velma.grimmig.mine.nu
------------
Succeeded: 2
Failed:    0
------------
Total states run:     2
Total run time: 209.613 ms
bakerstreet.grimmig.mine.nu:
----------
          ID: /etc/krb5.keytab
    Function: file.managed
      Result: True
     Comment: File /etc/krb5.keytab is in the correct state
     Started: 15:55:53.605824
    Duration: 456.494 ms
     Changes:   
----------
          ID: /etc/krb5.conf
    Function: file.managed
      Result: True
     Comment: File /etc/krb5.conf is in the correct state
     Started: 15:55:54.063406
    Duration: 268.367 ms
     Changes:   

Summary for bakerstreet.grimmig.mine.nu
------------
Succeeded: 2
Failed:    0
------------
Total states run:     2
Total run time: 724.861 ms
  • Setup sshd service by making the following settinging in /etc/ssh/sshd_config file:
KerberosAuthentication yes
KerberosOrLocalPasswd no
KerberosTicketCleanup yes
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes 
# The following will disable interactive logons, and may optionally also be applied.
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

  • Restart the sshd service using sudo systemctl restart sshd.

  • Testing

    1. Check token acquired by logon.
    • Go to each machine and login.
    • From terminal, run klist and you should see kerberos token matching login time.
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_Omhc4N
Default principal: chuck@GRIMMIG.MINE.NU

Valid starting       Expires              Service principal
10/29/2019 16:55:39  10/30/2019 08:55:39  krbtgt/GRIMMIG.MINE.NU@GRIMMIG.MINE.NU
	renew until 10/30/2019 16:55:39
  1. Check ssh connectivity uses Kerberos.
    • ssh should work if you have a Kerberos token.
    • ssh should fail if you do not have a kerberos token.
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_Omhc4N
Default principal: chuck@GRIMMIG.MINE.NU

Valid starting       Expires              Service principal
10/29/2019 17:47:20  10/30/2019 09:47:20  krbtgt/GRIMMIG.MINE.NU@GRIMMIG.MINE.NU
	renew until 10/30/2019 17:47:20
$ ssh velma
chuck@velma ~ $ exit
Connection to velma closed.
$ kdestroy
$ ssh velma
chuck@velma: Permission denied (publickey,gssapi-with-mic).
$