Chapter 18. Remote Access to Hosts

18.1. Terminal Access (Telnet)

Telnet allows a user to remotely access a command shell on another computer. Telnet is supported by most platforms on the Internet, including not only Unix and Windows NT,[79] but even some MS-DOS and Microsoft Windows systems (which provide access to a DOS shell via a Telnet server). The major exception is the Macintosh operating system, which doesn't have a command line-oriented shell to give users access to, regardless of whether or not they're local (unless you install the Unix-style development environment, which gives you both the shell and the Telnet server).

[79]Windows 2000 includes both the client and the server; Windows NT 4 includes only a Telnet client, but Telnet servers for it are available from third parties or as part of the Windows NT Resource Kit.

Although remote terminal access is the most common use of Telnet, most Telnet clients support the specification of arbitrary port numbers to access text-based TCP services at other ports. This is useful if you have a service for which you don't want to distribute a dedicated client; for example, it's often used to give access to MUDs (Multi-User Domains) and MOOs (Multi-user domains, Object Oriented), which are multi-user environments for games, collaborative work environments, or chat areas. Telnet clients are also used fairly often for debugging protocols that are normally accessed by dedicated clients. For example, people will check SMTP servers or verify usernames by using telnet hostname 25 to connect to the SMTP server directly on port 25 and type SMTP commands to it. It's important to understand that, although you may be using the program named telnet for these purposes, all it's doing is opening a simple TCP connection to the specified port number. The telnet program doesn't initiate the Telnet protocol (which provides for things like option negotiation between client and server, line-at-a-time and character-at-a-time modes, and so on) unless it is talking to a server on the standard Telnet port (port 23).[80] This section discusses only the use of Telnet clients to access Telnet servers.

[80]Although Telnet does not initiate negotiation except when talking to port 23, most Telnet clients will still respond to negotiation requests, which can be used by servers to detect people using Telnet instead of standard clients (for instance, people using Telnet to port 25 to attempt to forge email).

Incoming and outgoing Telnet have very different security implications. Most sites want to allow their users access to outgoing Telnet service, so their users can get to command shells and information services provided via Telnet on remote systems on the Internet. (Figure 18-1 illustrates outbound Telnet.) On the other hand, most sites don't want to allow (or want to allow but very strictly control) incoming Telnet access to their site.

Figure 18-1. Outbound Telnet

Regardless of whether the access is incoming or outgoing, Telnet is a cleartext protocol (just like most others). Whatever information your users access or provide over a Telnet session (for example, accessing sensitive data or providing their passwords for other systems) is going to be visible to someone snooping on the Telnet connection. The exception to this is Windows 2000 Telnet, which is discussed later in this chapter; in some circumstances, it protects the authentication information, but any other information on the connection will still be visible. Encrypting versions of Telnet are available, but none are widely deployed. Most sites that need encrypted terminal access use SSH instead. (See Section 18.2.5, "Secure Shell (SSH)" later in this chapter for a discussion of SSH.)

Users should be warned to use different passwords on external hosts from those they use on your hosts. When they make outgoing Telnet connections, their passwords may be sniffed. (See Chapter 21, "Authentication and Auditing Services", for more information about passwords and password sniffing.)