telnetd(1M)

DESCRIPTION

The telnetd daemon executes a server that supports the DARPA standard TELNET virtual terminal protocol. The Internet daemon (inetd) executes telnetd when it receives a service request at the port listed in the services data base for telnet using the tcp protocol (see inetd(1M) and services(4)).

telnetd operates by allocating a Telnet pseudo-terminal device (see tels(7)) for a client, then creating a login process which has the slave side of the Telnet pseudo-terminal as stdin, stdout, and stderr. telnetd manipulates the master side of the Telnet pseudo-terminal, implementing the TELNET protocol, and passing characters between the client and login process.

NOTE: telnetd no longer uses pty(7) devices; instead it uses special devices created for TELNET sessions only. For a full description, see tels(7).

When a TELNET session is started up, telnetd sends TELNET options to the client side, indicating a willingness to do remote echo of characters, to suppress go ahead, and to receive terminal speed, terminal type, and authentication information from the remote client. If the remote client is willing, the remote terminal type is propagated in the environment of the created login process. The Telnet pseudo-terminal allocated to the client is configured as a normal terminal with the exception of echoing characters (see tty(7)).

The flow control option permits applications running on a remote host to toggle the flow control on the local host. To toggle flow control for a telnet session programmatically, the application program must first call the tcgetattr function to get the current termios settings. For example,

Then, the c_iflag of the termios structure must have IXON set(reset) to enable(disable) flow control.

Finally, the tcsetattr function call can implement the change. For example,

To toggle the flow control interactively, the user can issue a stty command using the input options -ixon to disable, or ixon to enable flow control. (see stty(1)).

The terminal speed option permits applications running on a remote host to obtain the terminal speed of the local host session using either ioctl or stty.

By default, the telnet server provides remote execution facilities with authentication based on Kerberos V5. (See sis(5).)

The telnet server also supports the TAC User ID (also known as the TAC Access Control System, or TACACS User ID) option, whereby users telneting to two or more consenting hosts may avoid going through a second login sequence.

To start telnetd from the Internet daemon, the configuration file /etc/inetd.conf must contain an entry as follows:

To override the standard telnetd login banner, specify a file containing a custom banner with the -b bannerfile option. For example, to use /etc/issue as the login banner, have inetd start telnetd with the following lines in /etc/inetd.conf (\ provides line continuation):

If bannerfile is not specified, telnetd does not print a login banner.

With this Kerberos version of telnetd, inetd can start telnetd with the following lines in /etc/inetd.conf:

or

The -A option is used to ensure that non-secure systems are denied access to the server. It overrides any value specified with the -a option except when authmode is debug. (See sis(5).)

The -a authmode option specifies what mode is to be used for Kerberos authentication. (See sis(5).) Values for authmode are:

The system administrator can enable the TAC User ID option on servers designated as participating hosts by having inetd start telnetd with the -t option in /etc/inetd.conf:

In order for the TAC User ID option to work as specified, the system administrator must assign to all authorized users of the option the same login name and unique user ID (UUID) on every participating system to which they are allowed TAC User ID access. These same UUIDs should not be assigned to non-authorized users.

Users cannot use the feature on systems where their local and remote UUIDs differ, but they can always use the normal telnet login sequence. Also, there may be a potential security breach where a user with one UUID may be able to gain entry to participating systems and accounts where that UUID is assigned to someone else, unless the above restrictions are followed.

A typical configuration may consist of one or more secure front-end systems and a network of participating hosts. Users who have successfully logged onto the front-end system may telnet directly to any participating system without being prompted for another login.

telnet uses the same files as rlogin to verify participating systems and authorized users, hosts.equiv and .rhosts. (See hosts.equiv(4) and the Managing Systems and Workgroups manual for configuration details.)

DIAGNOSTICS

If any error is encountered by telnetd in establishing the connection, an error message is returned through the connection, after which the connection is closed and the server exits. Any errors generated by the login process or its descendents are passed through as ordinary data.

Diagnostic messages displayed by telnetd are displayed below. Kerberos specific errors are listed in sis(5).

WARNINGS

The terminal type name received from the remote client is converted to lowercase.

telnetd never sends TELNET go ahead commands.

AUTHOR

telnetd was developed by the University of California, Berkeley.

SEE ALSO

login(1), rlogin(1), stty(1), telnet(1), inetd(1M), inetsvcs_sec(1M), ioctl(2), hosts(4), inetd.conf(4), inetd.sec(4), services(4), sis(5), tels(7), tty(7).

Managing Systems and Workgroups.

DOD MIL_STD 1782.

RFC 854 for the TELNET protocol specification.