Set up single sign-on (SSO) for SSH with LDAP and Kerberos

• Tweet
• Sumo

• Tweet

Even without distributing SSH keys, SSH login can be set up as single sign-on – provided LDAP and Kerberos are in place.

If you already have LDAP and Kerberos in the network, SSH login can be set up on multiple servers without a password – without having to distribute SSH keys. However, this requires that all systems use central user administration via LDAP and that the hosts and users have a Kerberos principal. In addition, the host names of client and server must be resolvable via DNS – both forwards and backwards (reverse DNS).

GSSAPI (Generic Security Service Application Programming Interface) is used for authentication via Kerberos on an SSH server. However, GSSAPI cannot be used for the initial authentication of a user. If you want to log on to a system via GSSAPI, you must have performed Kerberos authentication beforehand. This is done either automatically by logging on to the system or after logging in with the kinit command.

The first step is to adapt the SSH server by changing the file / etc / ssh / sshd_config:

GSSAPIAuthentication yes
GSSAPIStoreCredentialsOnRekey yes
GSSAPIKeyExchange yes

Restarting sshd will make the changes take effect. The configuration parameters have the following meanings:

• GSSAPIAuthentication enables authentication via the GSSAPI. The parameter must be set both on the server and on the client. The default value for the parameter is no.
• By setting GSSAPIStoreCredentialsOnRekeygt the keys of a user are updated automatically.
• GSSAPIKeyExchange allows the exchange of the GSSAPI keys. It is not based on the SSH keys.

There are two ways to configure the SSH client. Either root adjusts the central file / etc / ssh / ssh_config. Or each user must create and adapt their own SSH client configuration file ~ / .ssh / config. In both cases the entries are identical.

The configuration can be done either for a specific host with its FQDN or using * as a wildcard for the host name. This allows several hosts to be combined under one configuration:

Host ldapserver.example.net
GSSAPIAuthentication yes

Host *.example.com
GSSAPIAuthentication yes

Host *
GSSAPIAuthentication no

In this example, authentication via GSSAPI is activated when connecting to the host ldapserver.example.net, but not to all other hosts in the domain example.net. For the domain example.com, GSSAPI authentication is activated for all hosts. No GSSAPI authentication is used for any other host. The following listing shows the tickets and the registration process on the server ldapserver.example.net.

jdoe@c1:~$ klist
Ticket cache: FILE:/tmp/krb5cc_10500_Q8iDCb
Default principal: jdoe@EXAMPLE.NET
Valid starting Expires Service principal
2020-06-15T14:43:34 2020-06-16T00:43:34 krbtgt/EXAMPLE.NET@EXAMPLE.NET
renew until 2020-06-16T14:43:34
jdoe@c1:~$ ssh ldapserver.example.net
…
jdoe@ldapserver:~$ klist
klist: No credentials cache found (filename: /tmp/krb5cc_10500)

Authentication via GSSAPI was successful. If you additionally specify the -v parameter when executing the SSH login, you can exactly understand the authentication process.

At this point, your own TGT (Ticket Granting Ticket) is not forwarded to the SSH server. To do this, root must change the file /etc/krb5.conf on each client concerned.

[appdefaults]
forwardable = yes
forward = yes

On all adapted clients, registered users can now take their TGT with them and from there immediately perform a passwordless login to services and other servers. To take the TGT to an SSH server, use the -K option. The following listing shows the individual steps.

jdoe@c1:~$ klist
Ticket cache: FILE:/tmp/krb5cc_10500_Wc76XL
Default principal: jdoe@EXAMPLE.NET
Valid starting Expires Service principal
2020-06-18T15:36:29 2020-06-19T01:36:29 krbtgt/EXAMPLE.NET@EXAMPLE.NET
renew until 2020-06-19T15:36:29
jdoe@c1:~$ ssh -K ldapserver.example.net
…
jdoe@ldapserver:~$ klist
Ticket cache: FILE:/tmp/krb5cc_10500_IEsYKlWm3b
Default principal: jdoe@EXAMPLE.NET
Valid starting Expires Service principal
2020-06-18T15:37:15 2020-06-19T01:36:29 krbtgt/EXAMPLE.NET@EXAMPLE.NET
renew until 2020-06-19T15:36:29
jdoe@ldapserver:~$ exit
logout
Connection to ldapserver.example.net closed.

jdoe@c1:~$ klist
Ticket cache: FILE:/tmp/krb5cc_10500_Wc76XL
Default principal: jdoe@EXAMPLE.NET
Valid starting Expires Service principal
2020-06-18T15:36:29 2020-06-19T01:36:29 krbtgt/EXAMPLE.NET@EXAMPLE.NET
renew until 2020-06-19T15:36:29
2020-06-18T15:37:15 2020-06-19T01:36:29 host/ldapserver.example.net@EXAMPLE.NET
renew until 2020-06-19T15:36:29

After logging out of the SSH server, its service ticket is added to the user’s ticket list. The next time you log on to the same server, the client will now use the server’s service ticket and no longer the TGT. Since the SSH server has issued the service ticket, it does not have to carry out an additional check the next time it logs on. However, the client can also be configured so that it automatically transfers the TGT without having to use the -K switch.

Host ldapserver.example.net
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Host *.example.com
GSSAPIAuthentication yes

This means that the TGT must always be taken with you when you log on to the ldapserver.example.net server. However, all hosts of the domain example.com still require the parameter -K to forward the TGT.

However, it should be noted that anyone who sets up the SSH connection to all systems via single sign-on should never leave their own workstation without a locked screen. Because every user automatically receives a TGT when they log in, SSH login works on all appropriately configured servers without a password.

And there you have it. All necessary steps to use SSO (Single Sign-on for SSH using LDAP and Kerberos.