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:
/etc/xinetd.d/krb5-telnet:
service telnet
{
...
disable = no
}
and disable the standard Telnet daemon:
/etc/xinetd.d/telnet:
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 Trying 10.1.1.6... Connected to moof.dogood.org (10.1.1.6). 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. moof$
You now have an encrypted Telnet connection, strongly and automatically authenticated via Kerberos.
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:
/etc/xinetd.d/krb5-telnet:
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
Trying 10.1.1.6...
which prints details about the Telnet authentication and encryption negotiation.
Get Linux Security Cookbook now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.