Prepared By Visolve SSH Team
Internet connects tens of millions of computers across the globe. The Internet Protocol suite, including the TCP/IP, provides reliable and scalable communications over the real-world networks. However, as Information espionage has become a major problem in Internet now-a-days, this vast network is prone/vulnerable to many malicious attacks such as eavesdropping, connection hijacking, IP spoofing, etc. Using Secure Shell with Kerberos authentication is an ideal choice for preventing these types of network risks and threats. This paper discuss about setting up of Kerberos environment and how to configure the Kerberos and Secure Shell to ensure secure and reliable communication over the network. There are two versions of Kerberos available, Kerberos4 and Kerberos5. This guide discuss only on Kerberos5. Those who want to know the introduction to Kerberos and OpenSSH, may move on to the next section. If you want to look at the configuration of Kerberos and OpenSSH, you can skip this section and directly go to Configuring Kerberos environment for setting up the Kerberos environment on Linux with OpenSSH. For setting up a Kerberos environment on HP-UX with HP-UX Secure Shell, see, Setting up a Kerberos environment for HP-UX Secure Shell
Authentication and Authorization
In any network communication, the two stages that the user has to pass through, for getting connected to a remote system and getting access to the resources on the remote system are "Authentication" and "Authorization".
Authentication is "the process of verifying an identity claimed by or for a system entity". This is to provide assurance that users (or systems) are who they say they are. Thus, authentication process compares, what user has, to a known constant that is trusted. Most of the time this is done by interacting with the user like getting the username and password. Other forms with the by proxy such as smartcard where the authentication tokens will be stored. These standards are described in RFC 2828 (Internet Security Glossary, May 2000).
Authorization refers to a user's ability to access resources on a network, based on user account privileges and rights. This is also known as "access control". Only a user who succeeded in authentication will enter to this authorization phase.
Kerberos, developed and released by MIT, is an AA [Authentication and Authorization] system. Kerberos has two purposes, security and authentication. In most distributed network system, most of the time, password is used to prove user's identity, and password must be transmitted over the network from the client machine to the machine that the user wants to access. So, a mechanism that prevent anyone from intercepting or eavesdropping on the transmitted plain passwords is vital for security. Also another pain in using password for the authentication is, the password has to be supplied each and every time a connection is requested to the remote machine. Kerberos help users to avoid this pain and the central problem solved by Kerberos is how to use passwords for authentication without sending them over the network.
The following infrastructure are required for setting up a Kerberos environment
Although Kerberos provides some minimal level of authorization facilities, it is limited only for the permissions that the user can have to modify the KDC database. Thus, the individual applications need to take care of the authorization part.
This document is mainly for guiding users in configuring Kerberos to use with OpenSSH. For more information about Kerberos and other terms discussed about Kerberos, click here - "How Kerberos authentication works?".
OpenSSH, primarily developed by the OpenBSD Project, is a free version of the SSH protocol suite of network connectivity tools. OpenSSH encrypts all traffic (including passwords) to effectively eliminate eavesdropping, connection hijacking, IP spoofing and other network level attacks. This distribution provides many authentication methods and one among that is the Kerberos authentication.
OpenSSH and HP-UX Secure Shell supports SSH Protocol versions 1.3, 1.5 and 2.0. As per the current version of OpenSSH [4.3p2],the Kerberos authentication is done via their Kerberos credentials and the authenticated users are allowed to forward their credentials to a remote machine over ssh. Kerberos authentication support is available for SSH protocols 1 and 2. For SSH protocol 2.0, GSSAPI support is also available. In addition to other authentication mechanism support, GSSAPI facilitates authentication with Kerberos also.
Before getting into the details of configuration, some of the definitions to be known.
Realm: The realm is an administrative division identifying a single instance of Kerberos principal database. Each host is given a realm name. If you are maintaining a KDC for your domain xyz.org, then the realm is the name for the host on which this KDC service is running. Realm names are usually in capital letters [normal convention]. So, the realm name for your example domain is XYZ.ORG. This realm will have a database that holds the user principals.
Principal: A principal is essentially a username for the realm. Each user needs a principal in the realm. This is of the form, principal_name@REALM. For example, sshteam@VISOLVE.COM. In addition to a principal, you must have an account on each machine in the network that comes under this realm, that you will use. If the principal name and the account name are the same, then there are more conveniences.
Ticket: A record that helps a client authenticate itself to a server; it contains the client's identity, a session key, a timestamp, and other information, all sealed using the server's secret key. It only serves to authenticate a client when presented along with a fresh Authenticator.
TGT: Ticket Granting ticket is issued by AS [Authentication Server - a component in KDC], to client for the desired application service, which is encrypted by the client's secret key.
Configuring the Kerberos environment
The following are the requirements for setting up Kerberos on Linux [to use with OpenSSH]
To demonstrate the steps, we have used the following names for the systems in the network.
| XYZ.ORG | Realm name. The domain the KDC is running for. |
| kdcserver.xyz.org | The hostname where KDC is running |
| sshserver.xyz.org | The ssh server hostname |
| sshclient.xyz.org | The ssh client hostname |
| krbuser | A user. The principal for this user has to be added to the KDC, and this user must have an account on the sshserver.xyz.org. |
The following steps have to be followed to install Kerberos on all the machines, the KDC system, the Server [where SSH server is installed] and the Client machine where SSH client is installed..
The Kerberos installation steps may vary from one Linux distribution to the other. If an rpm is available for Kerberos in the Linux distribution you are using, then install that rpm on all the systems.
Installing Kerberos from source or rpm
The following rpms have to be installed. The versions numbers may differ. Here, the version taken is "1.2.7-10". This is taken on Redhat 9.0.
The command to install an rpm on Linux is given below.
# rpm -ivh <rpm_name>
Otherwise, follow these instructions to build Kerberos on your Linux Systems.
cd /usr/local
tar -xvzf krb5-1.3.1.tar.gz
[Ex: We have used 1.3.1 version of Kerberos5 source]cd krb5-1.3.1
./configure--prefix=/usr/local/krb5
make
make install
As explained already, KDC is the main component of Kerberos. The host that runs the KDC will have a name [Realm] and this consists of a database [list of principals]. The following steps have to be followed for configuring the KDC.
Configuring the KDC
Sample configuration files are given here. The kdc.conf and kadm5.acl files must be present in the KDC server. The other file krb5.conf must be present on all the machines. These files reflect the details about the realm, the domain-realm mappings and the access privileges for the principals to access the Kerberos database. To setup your own realm and domain, just replace the XYZ.ORG in all the files with your domain name. By convention, all realm names should be in uppercase letters and all DNS hostnames and domain names should be in lower case letters.
| KDC Configuration file : kdc.conf |
|---|
# /etc/kdc.conf - Kerberos Key Distribution Center - Configuration File
[kdcdefaults]
kdc_ports = 88
[realms]
XYZ.ORG = {
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
admin_keytab=/usr/local/krb5/var/krb5kdc/kadm5.keytab
acl_file=/usr/local/krb5/var/krb5kdc/kadm5.acl
master_key_type = des3-hmac-sha1
supported_enctypes = des3-hmac-sha1:normal des-cbc-
crc:normal des-cbc-crc:v4
kdc_supported_enctypes = des3-hmac-sha1:normal des-cbc-
crc:normal des-cbc-crc:v4
}
[logging]
kdc = FILE:/usr/local/krb5/var/krb5kdc/kdc.log
admin_server = FILE:/usr/local/krb5/var/krb5kdc/kadmin.log
|
| ACL - Access Control List : kadm5.acl |
|---|
# /usr/local/var/krb5/krb5kdc/kadm5.acl - Access Control List configuration File
*/admin@XYZ.ORG *
|
| Managing KDC database [ Creating KDC database, Adding user principals ] |
|---|
1. First a database has to be created in the KDC host to hold the principals of the users and hosts. The command given here will create the database files. These files will be created in /usr/local/krb5/var/krb5kdc/.
# /usr/local/krb5/sbin/kdb5_util create -r XYZ.ORG -s
2. This realm [KDC host] needs an administrator. Thus, an entry has to be added in the database for the administrator. The following command do that job.
# /usr/local/krb5/sbin/kadmin.local -q "addprinc useradmin/admin@XYZ.ORG"
Passwd: * * * * * *
3. The next step is to create a keytab for kadmind [the Kerberos administration server]. This keytab is a file where user keys will be stored and this key will be used by the kadmind to decrypt the administrators Kerberos tickets to determine whether or not it should give the database. This is done with the following command.
# /usr/local/krb5/sbin/kadmin.local -q \
"ktadd -k /usr/local/var/krb5kdc/kadm5.keytab =>kadmin/admin kadmin/changepw"
4. For every user in the network, if the user wants to connect to another machine with Kerberos authentication, then, the user must have a principal in the KDC. The following commands are used to add a principal for the user in the KDC database. There must be an user account in the server to which the user wants to connect with this Kerberos principal. For conveniencies, it is recommended to have same names for the user account in the server and the principal name in KDC. [See Principal].
# /usr/local/krb5/sbin/kadmin.local -q "addprinc krbuser"
5. Thus, the KDC is configured with a user principal for the user "krbuser". Once this is done, the Kerberos server has to be started.
# /usr/local/krb5/sbin/krb5kdc
# /usr/local/krb5/sbin/kadmind
|
Configuring the Application server system:
The Application server need a keytab file, called /etc/krb5.keytab, to authenticate to the KDC. In order to generate a keytab for a host, the host must have a principal in the Kerberos database. Follow the procedure for adding hosts to the database.
| Application server [SSH Server machine] |
|---|
1.Get the ticket from the KDC for the administrator principal. This command will result in a prompt for the admin password. Give a password for the admin.
# /usr/local/krb5/bin/kinit admin/admin
Passwd: * * * * * *
2. Now, the principal of the server [sshserver.xyz.org] must be added to the KDC.
# /usr/local/krb5/sbin/kadmin.local -q "addprinc -randkey host/sshserver.xyz.org"
3. Create a keytab file.This will create a keytab file in /etc/krb5.keytab.
# /usr/local/krb5/sbin/kadmin.local -q " ktadd -k /etc/krb5.keytab host/sshserver.xyz.org"
4. Check the correct information in the keytab file. ktutil is an utility for managing the keylist in keytab files. "rkt" means read keytab. "l" lists the current keylist in the keytab file. To know the correct server principal entry in the keytab file, ktutil command is used. "q" is used to quit from the kutil service.
# /usr/local/krb5/sbin/ktutil
ktutil: rkt /etc/krb5.keytab
ktutil: l
slot KVNO Principal
---- ---- --------------------------------------------
1 3 host/sshserver.xyz.org@XYZ.ORG
2 3 host/sshserver.xyz.org@XYZ.ORG
ktutil: q
|
Configuring the Application client system
Client machine needs the programs "kinit", "klist", "kdestroy" and the /etc/krb5.conf file which contains the KDC server details. The installation of kerberos-1.3.1 creates all the client programs in /usr/local/krb5/bin
Kerberos5 server can be used for the following authentications with OpenSSH.
OpenSSH must be available on the client and server machines. [on sshclient.xyz.org and sshserver.xyz.org respectively]. For more details about OpenSSH build and installation, see OpenSSH installation on Linux.
| GSS-API Authentication |
|---|
1. Edit the ssh server configuration file [by default, in /etc/ssh/sshd_config] on sshserver.xyz.org and ssh client configuration file [by default, in /etc/ssh/ssh_config] on sshclient.xyz.org. If you had given a different installation path for the OpenSSH application, then check sshd_config in "etc"directory in the installed path.
GSSAPIAuthentication yes
2. Start the sshd server on sshserver.xyz.org. By default the ssh server will run on port 22.
# /user/sbin/sshd
3. Make sure that the kdc server is running in the KDC machine , [kdcserver.xyz.org]
# ps -A |grep krb5kdc
If the server is not started, start by
# /usr/local/krb5-1.3.1/sbin/krb5kdc
# /usr/local/krb5-1.3.1/sbin/kadmind
4. Get a initial ticket ( TGT ) in the client machine [sshclient.xyz.org]
# kinit krbuser
Passwd: * * * * * *
5. Once a TGT is obtained, it can be checked as follows.
# klist
Ticket cache: FILE:/tmp/krb5cc_11190
Default principal: krbuser@XYZ.ORG
Valid starting Expires Service principal
01/09/04 12:41:09 01/09/04 22:41:09 krbtgt/XYZ.ORG@XYZ.ORG
6. Connect the ssh client with the server
# ssh krbuser@sshserver.xyz.org
Note: GSS-API authentication is a password less authentication. For a successful connection, the server should not ask for a password for the authentication. But, other authentications such as Publickey will also connect without password if there is proper key on the client and server. To make sure that GSS-API authentication is succeeded,the ssh client can be run in verbose mode. This can be done by using "-v" with the ssh client. The more the number of "v", the more the verbose details. The maximum number of "v" that can be given is 3.
# ssh krbuser@sshserver.xyz.org -vvv
......
debug1: Authentication succeeded (gssapi)
|
| Kerberos5 Authentication |
|---|
1. Edit the ssh server configuration file [by default, in /etc/ssh/sshd_config] on sshserver.xyz.org and ssh client configuration file [by default, in /etc/ssh/ssh_config] on sshclient.xyz.org. If you had given a different installation path for the OpenSSH application, then check sshd_config in "etc" directory in the installed path.
KerberosAuthentication yes
2. Start the sshd server on sshserver.xyz.org. By default the ssh server will run on port 22.
# /usr/sbin/sshd
3. Make sure that the kdc server is running in the KDC machine , [kdcserver.xyz.org]
# ps -A |grep krb5kdc
If the server is not started, start by
# /usr/local/krb5-1.3.1/sbin/krb5kdc
# /usr/local/krb5-1.3.1/sbin/kadmind
4. Destroy the ticket in the client machine
# kdestroy
5. Connect the ssh client with the server.
# ssh krbuser@sshserver.xyz.org
Note: In this authentication, the user will be prompted for a password. The password to be entered should be the "Kerberos password". This is the password that is used when "kinit" is done. |