Using Telnet

SSH is a far more secure and flexible protocol than is Telnet, but Telnet remains popular. Telnet is easy to implement and configure, so many small network appliances use this protocol. Even certain Internet applications sometimes use Telnet—typically specialized applications in which authentication isn't an issue. Because Telnet clients come with almost every major TCP/IP-enabled OS, running a Telnet server can be an appealing way to enable remote logins. Because the basic Telnet protocol doesn't support encryption, though, it's a poor choice when security is an issue. Crackers can too easily eavesdrop on a Telnet session to obtain passwords or other sensitive data. For this reason, I recommend you completely disable Telnet and use SSH instead whenever possible. If you must support Telnet logins for very old or exotic client computers, though, you can do so. In such cases, I recommend you at least limit your Telnet access to your local network; the risks of sending login passwords unencrypted over the Internet are simply too great.

Note The Kerberos suite ( provides an encrypted Telnet variant. This variant doesn't suffer from the same problems as the basic version of Telnet. Mandrake's default Telnet server supports Kerberos; however, it doesn't use Kerberos encryption unless your network hosts a Kerberos server and the client computers use Kerberos-enabled Telnet client programs. Debian also ships with an SSL-enabled Telnet (telnetd-ssl). This server supports encryption when communicating with a matched SSL-enabled client (telnet-ssI).

All major Linux distributions ship with Telnet clients and servers. Debian ships its server in a package called telnetd. Mandrake calls its server package telnet-server-krb5. Red Hat and SuSE both call their server packages telnet-server. Slackware embeds its server in the tcpip package. For the most part, these packages are not installed by default, but Slackware is an exception to this rule—the tcpip package contains many critical TCP/IP tools. Mandrake's default Telnet server handles both the original unencrypted Telnet and the Kerberos-enabled variant.

Telnet servers are almost always run via super servers. The default Debian, Slackware, and SuSE /etc/inetd.conf files include configurations for Telnet servers, but Slackware's and SuSE's are commented out by default. Mandrake and Red Hat both use xinetd by default, and their Telnet server packages include /etc/xinetd.d/telnet configuration files. Red Hat's file disables the server via a disable = yes line in this file, but Mandrake's configuration enables the server. In all cases, after you make a change to the super server configuration or install the server, you must restart or reinitialize the super server, as described in Chapter 22, to activate or deactivate the Telnet server. Typing killall -HUP inetd or killall -HUP xinetd should do the trick.

The default Telnet servers have no configuration files. The servers do accept some command-line options, though; consult the telnetd man page for details. Kerberos-enabled Telnet servers require extensive configuration to support Kerberos features, but Kerberos configuration is beyond the scope of this book.

Once the Telnet server is running, you can use a Telnet client to access the server system. Type telnet, followed by the name of the server system. Typically, you'll be asked for a username and password:

[email protected]:~$ telnet

Trying Connected to Escape character is 'A]\

Telnet Server login: paul Password:

Last login: Tue Apr 8 18:20:57 from bunyan [[email protected] paul]$

The exact information displayed during a Telnet login varies from one system to another, so what you see may differ from what's displayed here. As a general rule, though, you'll see at least the login: and Password: prompts, followed by your shell prompt. Other information may appear amidst these components, as shown in the preceding example.

Tip You can add a port number to a telnet call, as intelnet 25 to connect to port 25 on This option can be useful in debugging non-Telnet protocols. For instance, you might check whether a mail server is running by trying to connect to its port, and you might even manually issue commands to send mail. This technique doesn't work for all protocols, though. Some, such as most Domain Name System (DNS) transfers, use User Datagram Protocol (UDP) packets rather than the Transmission Control Protocol (TCP) packets used by Telnet. Other protocols rely on encrypted or binary data that's not easily generated via Telnet.

If you're using a non-Linux client computer, consult its documentation to learn where to find a Telnet client program. Telnet clients are available for almost all major OSs with TCP/IP stacks. One of the few that doesn't ship a Telnet client with its base OS or TCP/IP stack is Mac OS Classic. Several shareware and freeware Telnet clients are available for this OS, but it's better to bypass Telnet in favor of SSH if you must add software to the client. The more recent Mac OS X ships with a Telnet client.

0 0

Post a comment