Kevin's Blog [Index]

Return to blog

Configuring OpenSSH to use Kerberos Authentication

[link—standalone]

This article is a continuation of the last article about setting up an MIT krb5 server. We will configure OpenSSH to work using tickets from this server.

Modern OpenSSH uses GSSAPI to communicate with Kerberos. What this means is that despite the fact that there are configuration options that start with the word Kerberos, we should not be using them. These options are legacy options that only work over SSHv1 (now deprecated).

  1. Set a proper hostname
    2.   hostnamectl set-hostname client.kevco.virt
  2. Ensure time is synced using an NTP server

    3. By default, CentOS should have chronyd started and enabled, however, you may want to set up an ntpd server. It is very important that the kerberos server and clients have their time synced up. Otherwise, you will have problems authenticating.

  3. Install the Kerberos packages
    4.   yum install krb5-workstation krb5-libs
  4. Edit /etc/krb5.conf

    5. Configure this file in a similar manner to the server. Replace the example domain and realm with your domain and realm. Also make sure that you point to the correct kdc and admin server.

  5. Add an entry into /etc/hosts (optional if DNS configured)

    6. If you do not have DNS configured with the proper SRV and A records, you should add an entry pointing to the hostname of the kerberos server. Make sure that this hostname is the same as the Service Principal Name (SPN) you gave the server. You cannot have an entry in your /etc/hosts that is kerberos instead of kerberos.kevco.virt if you do not have an SPN matching host/kerberos@KEVCO.VIRT in your KDC.

  6. Create a service principal for this machine and add it to this machines keytab

    7. Each machine must have its own service principal and have its key stored in its own keytab. 

      kadmin -p admin/admin -q "addprinc -randkey host/server.kevco.virt"
  kadmin -p admin/admin -q "ktadd host/server.kevco.virt"
  7. Edit /etc/ssh/sshd_config and insert the following 
      GSSAPIAuthentication yes
  GSSAPICleanupCredentials yes
  GSSAPIStrictAcceptorCheck yes

    As stated before GSSAPI is the interface used by SSHv2 in order to authenticate with kerberos so it must be enabled. The second option is very important. GSSAPICleanupCredentials ensures that your credentials are destroyed on logout instead of staying in the cache. The reason this is important is that if an attacker gets into your machine, they can steal the ticket from this machine and Pass The Ticket to another server to which these credentials may provide access to. Finally, we enable the StrictAcceptorCheck which verifies that the SPN matches the hosts hostname. You can disable this if you have multiple aliases. You should probably disable password authentication at this point as well to reduce the attack surface.

  8. Add approved users to the ~/.k5login file or create a user

    9. There are two options you can use to allow users to log in to an account on your server using kerberos. The first option is to create a .k5login file in the home folder of the user you want the kerberos user to be allowed to log in as. In this case we will put it in the root users folder as this is an example (Please do not allow root user login to your SSH servers). You will place one User Principal Name (UPN) per line: 

      kdiaz@KEVCO.VIRT

    The second option is to simply create a new user that matches the username of the User Principal Name (UPN) that will be logging in. For example, kdiaz@KEVCO.VIRT will be able to log in to the kdiaz user on the server.

  9. Configure the client using steps 1-5 without forgetting to add the SPN matching hostname of the ssh server to your /etc/hosts file as well
  10. Edit the /etc/ssh/ssh_config on the client device
    11.   GSSAPIAuthentication yes
  GSSAPIDelegateCredentials no

    Once again we enable GSSAPI authentication so that we can use Kerberos. We also, depending on the environment, will disable GSSAPIDelegateCredentials. For this example, we do not need it. However, if you need the server to to obtain tickets on behalf of you, you can enable it. This may be important/useful in certain scenarios. If you do not need it, keep it off as an infected machine with the ability to request tickets on your behalf can cause you trouble.

  11. Get a ticket and test
    12.   kinit kdiaz
  ssh root@server.kevco.virt

    If all is well, you should now be able to use your ticket to log in to the configured user on your server. It is important that you use the proper hostname that matches the servers SPN to avoid trouble. It is also important that the key version number (kvno) of your SPNs and UPNs match throughout the two machines youre trying to get to communicate. It can be a source of headache. Errors such as this one can be found by running the SSH server in debug mode and attempting to authenticate. If you get an error due to the kvno of your UPN not matching, you can clear your credentials from the cache using kdestroy and reinitialize them with kinit. Additional debugging help can be done by also running the ssh client in verbose mode using the -v flag.