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.
1. Be
sure that time synchronization is in place between the Kerberos client and the
KDC. Refer to "configuring kerberos 5 server" for
more information. In addition, verify that DNS is working properly on the Kerberos
client before configuring the Kerberos client programs.
2. 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).
3. 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.
4. 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/blah.example.com
5. 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/blah.example.com
6. To use other kerberized network services,
they must first be started. Below is a list of some common kerberized services
and instructions about enabling them:
·
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.
