Recipe 4.15 Using Kerberos with Telnet

4.15.1 Problem

You want to use Telnet securely, and you have an MIT Kerberos-5 environment.

4.15.2 Solution

Use the Kerberos-aware ("Kerberized") version of telnet. Assuming you have set up a Kerberos realm [Recipe 4.11] and hosts [Recipe 4.13], enable the Kerberized Telnet daemon on your desired destination machine:

service telnet
        disable = no

and disable the standard Telnet daemon:

service telnet
        disable = yes

Then restart xinetd on that machine [Recipe 3.3] (suppose its hostname is moof):

moof# kill -HUP `pidof xinetd`

and check /var/log/messages for any error messages. Then, on a client machine (say, dogcow) in the same realm, DOGOOD.ORG:

dogcow$ kinit -f
Password for pat@DOGOOD.ORG:

dogcow$ /usr/kerberos/bin/telnet -fax moof
Connected to (
Escape character is '^]'.
Waiting for encryption to be negotiated...
[ Kerberos V5 accepts you as ``pat@DOGOOD.ORG'' ]
[ Kerberos V5 accepted forwarded credentials ]
Last login: Fri Mar  7 03:28:14 from localhost.localdomain
You have mail.

You now have an encrypted Telnet connection, strongly and automatically authenticated via Kerberos.

4.15.3 Discussion

Often, people think of Telnet as synonymous with "insecure," but this is not so. The Telnet protocol allows for strong authentication and encryption, though it is seldom implemented. With the proper infrastructure, Telnet can be quite secure, as shown here.

The -f flag to kinit requests forwardable credentials, and the same flag to telnet then requests that they be forwarded. Thus, your Kerberos credentials follow you from one host to the next, removing the need to run kinit again on the second host in order to use Kerberos there. This provides a more complete single-sign-on effect.

As shown, the Kerberized Telnet server still allows plaintext passwords if Kerberos authentication fails, or if the client doesn't offer it. To make telnetd require strong authentication, modify its xinetd configuration file:

service telnet
        service_args = -a valid

and restart xinetd again. Now when you try to telnet insecurely, it fails:

dogcow$ telnet moof
telnetd: No authentication provided.
Connection closed by foreign host.

If Kerberized authentication doesn't work, try the following to get more information:

dogcow$ telnet -fax
telnet> set authd
auth debugging enabled
telnet> set encd
Encryption debugging enabled
telnet> open moof

which prints details about the Telnet authentication and encryption negotiation.

4.15.4 See Also

telnet(1), telnetd(8).

    Chapter 9. Testing and Monitoring