Introduction

Kerberos technology enables Single Sign On (SSO). Theoretically, you can login to your workstation once, and then access files, shells, and webservers elsewhere in the realm without being prompted over and over again for your username and password. When you change your password, it is changed everywhere. Up until now, we have mainly concerned ourselves with setting up the DAS infrastructure and setting up clients so that console logins and SSH logins can be unified. What about SSO?

The Kerberos distribution includes new binaries for old network applications like TELNET and RLOGIN. These allow a Kerberos principal (user) who has already logged in and been granted a ticket to seamlessly login to other resources. In this section, we will show you how to configure and use standard Kerberized network services. The examples will be based on a Red Hat 9 (DAS client) application server.

The Daemons:

Red Hat and Fedora Core let you enable and disable Kerberized network service daemons via config files in the /etc/xinetd.d directory. The following files should be present:

All of these services can be protected by TCP Wrappers. This can be done by editing the /etc/hosts.allow and/or /etc/hosts.deny configuration files. Your iptables configuration can also be used to restrict access to the services.

TCP Ports:

These Kerberized services use TCP. The port numbers they use are listed in this table:

SERVICE TCP Port
klogin 543
eklogin 2105
krb5-telnet 23
gssftp 21
kshell 544

Prerequisites

These instructions assume the following:

Please note that time syncronization is very important here. If the time is +/- 5 minutes from the DAS server time, Kerberos will return an error.


Step-by-step Instructions

Step 1: Add a new host principal to the Kerberos database

From the kadmin CLI (which can be invoked on any DAS client or on DAS-M), add the new host principal for the app server to the Kerberos database. It is probably easiest to run this command from the app server, since you will need to add the hostkey to the keytab on the app server anyway. The host principal name must contain the FQDN of the server:

kadmin:  addprinc -randkey host/labdemo2.kerb.org
NOTICE: no policy specified for host/labdemo2.kerb.org@KERB.ORG; assigning "default"
Principal "host/labdemo2.kerb.org@KERB.ORG" created.

Step 2: Add the app server host principal to the app server's keytab

Now, on the app server (labdemo2.kerb.org), extract the host pricipal's key to the keytab as follows:

kadmin:  ktadd host/labdemo2.kerb.org
Entry for principal host/labdemo2.kerb.org with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/labdemo2.kerb.org with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.

Step 3: Configure /etc/hosts.allow for TCP Wrappers

This configuration file will limit what hosts can connect to the app server. This is separate from any firewall or packet filter setup you may have. In this example, we are allowing access from the loopback and the 10.10.22.0/24 network.

#
# hosts.allow   This file describes the names of the hosts which are
#               allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
                                                                                                                              
# Secure the Portmapper to our LAN
portmap : 127. 10.10.22. : ALLOW
portmap : ALL : DENY
                                                                                                                              
### Kerberized services ###
                                                                                                                              
## limit KLOGIN and EKLOGIN connections to local LAN and loopback
klogind : 127. 10.10.22. : ALLOW
klogind : ALL : DENY
                                                                                                                              
## limit TELNET connections to local LAN and loopback
telnetd : 127. 10.10.22. : ALLOW
telnetd : ALL : DENY
                                                                                                                              
## limit Kerberized FTP connections to local LAN and loopback
ftpd : 127. 10.10.22. : ALLOW
ftpd : ALL : DENY
                                                                                                                              
## limit RSH/RCP connections to local LAN and loopback
kshd : 127. 10.10.22. : ALLOW
kshd : ALL : DENY

Step 4: Enable the services by editing the config files in /etc/xinetd.d

klogin:

# default: off
# description: The kerberized rlogin server accepts BSD-style rlogin sessions, \
#              but uses Kerberos 5 authentication.
service klogin
{
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/kerberos/sbin/klogind
        server_args     = -5
        disable         = no
}

eklogin:

# default: off
# description: The encrypting kerberized rlogin server accepts rlogin sessions \
#              authenticated and encrypted with Kerberos 5.
service eklogin
{
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/kerberos/sbin/klogind
        server_args     = -e -5
        disable         = no
}

krb5-telnet:

# default: off
# description: The kerberized telnet server accepts normal telnet sessions, \
#              but can also use Kerberos 5 authentication.
service telnet
{
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/kerberos/sbin/telnetd
        server_args     = -a user
        log_on_failure  += USERID
        disable         = no
}

gssftp:

# default: off
# description: The kerberized FTP server accepts FTP connections \
#              that can be authenticated with Kerberos 5.
service ftp
{
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/kerberos/sbin/ftpd
        server_args     = -l -a
        log_on_failure  += USERID
        disable         = no
}

kshell:

# default: off
# description: The kerberized rshell server accepts rshell commands \
#              authenticated and encrypted with Kerberos 5.
service kshell
{
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/kerberos/sbin/kshd
        server_args     = -e -5
        disable         = no
}

Step 5: Restart xinetd

[root@labdemo2 xinetd.d]# /etc/init.d/xinetd restart
Stopping xinetd:                                           [  OK  ]
Starting xinetd:                                           [  OK  ]

Now use netstat to make sure the server is listening on the right ports:

[root@labdemo2 xinetd.d]# netstat -ta | grep LISTEN
tcp        0      0 *:kshell                *:*                LISTEN
tcp        0      0 *:sunrpc                *:*                LISTEN
tcp        0      0 *:ftp                   *:*                LISTEN
tcp        0      0 *:ssh                   *:*                LISTEN
tcp        0      0 *:telnet                *:*                LISTEN
tcp        0      0 *:eklogin               *:*                LISTEN
tcp        0      0 *:klogin                *:*                LISTEN

Now, as long as there is no firewall in the way, a DAS user should be able to login via Kerberized rlogin or telnet from any other DAS client in the realm, without entering a password.


Examples of Using the Kerberized Services

Below, there will be an example for each service. Some of the more common options will be explained. The client machine is ushas, the app server is labdemo2. The DAS user is "kitty".

Kerberized RLOGIN:

[kitty@ushas kitty]$ rlogin labdemo2.kerb.org
Last login: Tue Jun 15 09:09:51 from ushas
                                                                                                                          
######################
#                    #
#     LABDEMO2       #
#                    #
######################
                                                                                                                          
                                                                                                                          
You have mail.
[kitty@labdemo2 kitty]$ exit
Connection closed.

[kitty@ushas kitty]$ klist
Ticket cache: FILE:/tmp/krb5cc_6000_qyAG6p
Default principal: kitty@KERB.ORG
                                                                                                                          
Valid starting     Expires            Service principal
06/15/04 09:08:13  06/15/04 19:08:13  krbtgt/KERB.ORG@KERB.ORG
        renew until 06/15/04 09:08:13
06/15/04 09:08:35  06/15/04 19:08:13  host/labdemo2.kerb.org@KERB.ORG
        renew until 06/15/04 09:08:13

Note that Kerberized rlogin only encrypts the authentication traffic. The subsequent command-line traffic is transmitted in cleartext. Also, you can see that there is now a Kerberos ticket in Kitty's cache that allows user "kitty" to connect to labdemo2 and use Kerberized network services.

Kerberized and Encrypted RLOGIN:

[kitty@ushas kitty]$ rlogin -x labdemo2.kerb.org
This rlogin session is using DES encryption for all data transmissions.
Last login: Tue Jun 15 09:13:53 from ushas
                                                                                                                          
######################
#                    #
#     LABDEMO2       #
#                    #
######################
                                                                                                                          
                                                                                                                          
You have mail.
[kitty@labdemo2 kitty]$ netstat -tn | grep EST
tcp        0      0 10.10.22.41:2105      10.10.22.68:32831     ESTABLISHED

[kitty@labdemo2 kitty]$ exit
Connection closed.

[kitty@ushas kitty]$

The -x option to the rlogin command enables DES encryption of the entire command-line session. As you can see, it connects to the eklogin port, TCP 2105.

Kerberized TELNET:

The Kerberized TELNET service is similar to the Kerberized RLOGIN service. It will only encrypt the authentication information by default, the rest of the session is sent "in the clear". You must use the -a option to use TELNET in this fashion. If you do not specify the -a option (which attempts automatic login), the session will fail.

To encrypt the entire session, you need to use the -x option. Below, you will see examples of all three scenarios:

[kitty@ushas kitty]$ telnet labdemo2
Trying 10.10.22.41...
Connected to labdemo2.kerb.org (10.10.22.41).
Escape character is '^]'.
telnetd: No authentication provided.
Connection closed by foreign host.
[kitty@ushas kitty]$ telnet -a labdemo2
Trying 10.10.22.41...
Connected to labdemo2.kerb.org (10.10.22.41).
Escape character is '^]'.
[ Kerberos V5 accepts you as ``kitty@KERB.ORG'' ]
Last login: Tue Jun 15 09:28:47 from ushas
                                                                                                                          
######################
#                    #
#     LABDEMO2       #
#                    #
######################
                                                                                                                          
                                                                                                                          
You have mail.
[kitty@labdemo2 kitty]$ ls
mail  mycron  sshtest
[kitty@labdemo2 kitty]$ exit
Connection closed by foreign host.
[kitty@ushas kitty]$ telnet -x labdemo2
Trying 10.10.22.41...
Connected to labdemo2.kerb.org (10.10.22.41).
Escape character is '^]'.
Waiting for encryption to be negotiated...
[ Kerberos V5 accepts you as ``kitty@KERB.ORG'' ]
done.
Last login: Tue Jun 15 09:30:14 from ushas
                                                                                                                          
######################
#                    #
#     LABDEMO2       #
#                    #
######################
                                                                                                                          
                                                                                                                          
You have mail.

[kitty@labdemo2 kitty]$ netstat -tn
tcp        0      0 10.10.22.41:23        10.10.22.68:32841     ESTABLISHED
[kitty@labdemo2 kitty]$ exit
Connection closed by foreign host.

[kitty@ushas kitty]$

Kerberized FTP:

Once again, we have encrypted authentication with no data encryption for the basic command, and we have an encrypted data transfer if we use the -x option. GSS-API with Kerberos is the security mechanism. Other than that, the ftp program works as expected.

[kitty@ushas kitty]$ ftp labdemo2
Connected to labdemo2.kerb.org.
220 labdemo2.kerb.org FTP server (Version 5.60) ready.
334 Using authentication type GSSAPI; ADAT must follow
GSSAPI accepted as authentication type
GSSAPI authentication succeeded
Name (labdemo2:kitty):
232 GSSAPI user kitty@KERB.ORG is authorized as kitty
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd ISO
250 CWD command successful.
ftp> ls
227 Entering Passive Mode (10,10,22,41,181,148)
150 Opening ASCII mode data connection for /bin/ls.
total 95336
-rw-------    1 labuser  46399488 Jun 15 12:58 cd-puppy.iso
-rw-rw-r--    1 labuser  51109888 Jun 15 12:58 damnsmall-0.5.2.iso
-rw-rw-r--    1 labuser        54 Jun 15 12:58 damnsmall-0.5.2.md5.txt
226 Transfer complete.
ftp> get cd-puppy.iso
local: cd-puppy.iso remote: cd-puppy.iso
227 Entering Passive Mode (10,10,22,41,181,155)
150 Opening BINARY mode data connection for cd-puppy.iso (46399488 bytes).
226 Transfer complete.
46399488 bytes received in 4.1 seconds (1.1e+04 Kbytes/s)
ftp> quit
221 Goodbye.
[kitty@ushas kitty]$
[kitty@ushas kitty]$ ftp -x labdemo2
Connected to labdemo2.kerb.org.
220 labdemo2.kerb.org FTP server (Version 5.60) ready.
334 Using authentication type GSSAPI; ADAT must follow
GSSAPI accepted as authentication type
GSSAPI authentication succeeded
200 Data channel protection level set to private.
Name (labdemo2:kitty):
232 GSSAPI user kitty@KERB.ORG is authorized as kitty
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd ISO
250 CWD command successful.
ftp> ls
227 Entering Passive Mode (10,10,22,41,181,173)
150 Opening ASCII mode data connection for /bin/ls.
total 95336
-rw-------    1 labuser  46399488 Jun 15 12:58 cd-puppy.iso
-rw-rw-r--    1 labuser  51109888 Jun 15 12:58 damnsmall-0.5.2.iso
-rw-rw-r--    1 labuser        54 Jun 15 12:58 damnsmall-0.5.2.md5.txt
226 Transfer complete.
ftp> mget damnsmall*
mget damnsmall-0.5.2.iso? y
227 Entering Passive Mode (10,10,22,41,181,180)
150 Opening BINARY mode data connection for damnsmall-0.5.2.iso (51109888 bytes).
226 Transfer complete.
51109888 bytes received in 16 seconds (3.1e+03 Kbytes/s)
mget damnsmall-0.5.2.md5.txt? y
227 Entering Passive Mode (10,10,22,41,181,184)
150 Opening BINARY mode data connection for damnsmall-0.5.2.md5.txt (54 bytes).
226 Transfer complete.
54 bytes received in 0.017 seconds (3.2 Kbytes/s)
ftp> quit
221 Goodbye.
[kitty@ushas kitty]$

Kerberized Remote Shell (RSH):

The Kerberized rsh program is a little bit different than the other programs we have already looked at. By default, the Red Hat app server only allows encrypted RSH connections. The kshd program on the app server also enables the use of Kerberized RCP, the old Berkeley remote file copy utility. We will look at examples of using rsh and rcp:

[kitty@ushas kitty]$ rsh -x labdemo2 hostname
This rsh session is encrypting input/output data transmissions.
labdemo2.kerb.org

[kitty@ushas kitty]$

We ran the hostname command on the remote system, the session was encrypted.

Now, let's look at rcp and copy a large file from the app server to the local host:

[kitty@ushas kitty]$ rcp -x labdemo2:ISO/test.iso /home/kitty/testcopy.iso

[kitty@ushas kitty]$ ls -lh testcopy.iso
-rw-------  1 kitty labuser 45M Jun 15 15:13 testcopy.iso

Now, we will copy a large file from the local host to the remote app server. The entire file transfer will be encrypted:

[kitty@ushas kitty]$ rcp -x cd-puppy.iso labdemo2:/home/kitty

Notes

Although there were examples for all of the different services, you probably would not want to enable all of them in production use. For example, if you already have SSH working with global passwords/UIDs/GIDs, why would you need TELNET? If you want to run Kerberized RLOGIN, why not use eklogin/rlogin -x instead of the unencrypted version? In our lab, the only Kerberized services that we normally enable are eklogin and kshell. Everything else can be done with SSH, SCP, and SFTP. I do not like the idea of running unencrypted data sessions for FTP, TELNET, and RLOGIN. The user may type in or view sensitive data "in the clear" after Kerberos authentication is over, thus compromising system security.

Another standard Kerberized service/program is ksu. We do not use it, but it is included with standard MIT Kerberos distributions.

Many Kerb5 programs/commands have "-f" or "-F" options for dealing with ticket forwarding. If you are interested in this feature, read the MIT Kerberos documentation on forwardable tickets.

References

Manpages: