3.3. Configuring a Kerberos 5 Client

Setting up a Kerberos 5 client is less involved than setting up a server. At a minimum, install the client packages and provide each client with a valid krb5.conf configuration file. While ssh and slogin are the preferred method of remotely logging in to client systems, Kerberized versions of rsh and rlogin are still available, though deploying them requires that a few more configuration changes be made.

Be sure that time synchronization is in place between the Kerberos client and the KDC. Refer to Section 3.2, “Configuring a Kerberos 5 Server” for more information. In addition, verify that DNS is working properly on the Kerberos client before configuring the Kerberos client programs.
Install the krb5-libs and krb5-workstation packages on all of the client machines. Supply a valid /etc/krb5.conf file for each client (usually this can be the same krb5.conf file used by the KDC).
Before a workstation in the realm can use Kerberos to authenticate users who connect using ssh or Kerberized rsh or rlogin, it must have its own host principal in the Kerberos database. The sshd, kshd, and klogind server programs all need access to the keys for the host service's principal. Additionally, in order to use the kerberized rsh and rlogin services, that workstation must have the xinetd package installed.
Using kadmin, add a host principal for the workstation on the KDC. The instance in this case is the hostname of the workstation. Use the -randkey option for the kadmin's addprinc command to create the principal and assign it a random key:
```
addprinc -randkey host/server.example.com
```
Now that the principal has been created, keys can be extracted for the workstation by running kadmin on the workstation itself, and using the ktadd command within kadmin:
```
ktadd -k /etc/krb5.keytab host/server.example.com
```
To use other kerberized network services, the krb5-server package should be installed, and the services must first be started, as listed in Table 3.3, “Common Kerberized Services”.

Table 3.3. Common Kerberized Services

Service Name	Usage Information
ssh	OpenSSH uses GSS-API to authenticate users to servers if the client's and server's configuration both have `GSSAPIAuthentication` enabled. If the client also has `GSSAPIDelegateCredentials` enabled, the user's credentials are made available on the remote system.
rsh and rlogin	To use the kerberized versions of `rsh` and `rlogin`, enable `klogin`, `eklogin`, and `kshell`.
Telnet	To use kerberized Telnet, `krb5-telnet` must be enabled.
FTP	To provide FTP access, create and extract a key for the principal with a root of `ftp`. Be certain to set the instance to the fully qualified hostname of the FTP server, then enable `gssftp`.
IMAP	To use a kerberized IMAP server, the `cyrus-imap` package uses Kerberos 5 if it also has the `cyrus-sasl-gssapi` package installed. The `cyrus-sasl-gssapi` package contains the Cyrus SASL plugins which support GSS-API authentication. Cyrus IMAP should function properly with Kerberos as long as the `cyrus` user is able to find the proper key in `/etc/krb5.keytab`, and the root for the principal is set to `imap` (created with `kadmin`). An alternative to `cyrus-imap` can be found in the `dovecot` package, which is also included in Red Hat Enterprise Linux. This package contains an IMAP server but does not, to date, support GSS-API and Kerberos.
CVS	To use a kerberized CVS server, `gserver` uses a principal with a root of `cvs` and is otherwise identical to the CVS `pserver`.