telnetd(ADMN)

telnetd -- TELNET protocol server

Syntax

Description

The telnetd command is a server which supports the Internet standard TELNET virtual terminal protocol; telnetd is invoked by the Internet server (see inetd(ADMN)), normally for requests to connect to the TELNET port as indicated by the /etc/services file (see services(SFF)).

The -debug option can be used to start up telnetd manually, instead of through inetd(ADMN). If started up in this manner, port may be specified to run telnetd on this alternate TCP port number.

The -b option specifies a banner file to be displayed. The default banner file is /etc/issue. If banner_file is specified as none, no banner file will be displayed.

Normally, telnetd displays the system release, hostname, and terminal port prior to the login prompt. The -h option stops telnetd from displaying this information.

The -r pty option specifies pseudo-terminal (pty) to use, where pty) can be specified in one of the following ways:

-r ptynum: use only the specified pty number, ptynum
-r low-: use ptys starting at pty number low
-r -high: use ptys from 0 through pty number high
-r low-high: use ptys in the specified range

The -r option is generally useful in the following situations:

Restrict telnetd to using ptys in a given range, so that other ptys can be dedicated to other functions.
Assign a telnetd that is bound to a particular non-standard port a specific pty so that a login on that port will always get the same pty name (as required by some older applications created when hard-wired serial terminals were the norm).

The -D option can be used for debugging purposes. This will allow telnet to print out debugging information to the connection, thus enabling the user to see what telnetd is doing. Several modifiers are available for the debugging mode:

exercise: Exercise client (not currently implemented).
netdata: Display the received data stream.
options: Print information about the negotiation of the TELNET options.
ptydata: Display data passed to the pseudo-terminal.
report: Print the options information, as well as some additional information about what processing is going on.

The telnetd command operates by allocating a pseudo-terminal device for a client, thereby creating a login process which has the slave side of the pseudo-terminal serving as stdin, stdout, and stderr. The master side of the pseudo-terminal opens the In-Kernel Network Terminal (IKNT) driver, which provides reliable, flow-controlled, two-way transmission of data between the master side of the pseudo-terminal and the underlying transport driver, bypassing the telnetd server. See the iknt(ADMP) manual reference page for a more detailed explanation. If the IKNT driver detects the transmission of a TELNET control command, it returns control of the master side of the pseudo-terminal to the telnetd server; this results in control characters flowing through the telnetd server, bypassing the IKNT driver.

When processing of TELNET control commands has completed, telnetd returns control of the pseudo-terminal master side to the IKNT driver.

Should the IKNT driver link fail, telnetd takes control of the master side of the pseudo-terminal and controls the routing of characters between the remote client and the login process.

When a TELNET session is started up, telnetd will send TELNET options to the client side which will indicate a willingness to:

do remote echo of characters,
suppress go ahead,
do remote flow control, as well as
receive terminal type information,
receive terminal speed information, and
receive window size information from the remote client.

If the remote client is willing, the remote terminal type will be propagated to the environment of the created login process. The pseudo-terminal allocated to the client will be configured to operate in ``cooked'' mode, with TAB3 and ICRNL enabled. In addition, telnetd unconditionally clears ISTRIP for the pseudo/slave pty (see termio(M)).

The telnetd command is willing to do: echo, binary, suppress go ahead, and timing mark.

The telnetd command is also willing to have the remote client do: binary, terminal type, terminal speed, window size, toggleflow control, environment, Xdisplay location, and suppress go ahead.

Keepalives

Transport-level keepalive messages are enabled unless the -n option is present. The use of keepalive messages allows sessions to be timed out if the client crashes or becomes unreachable.

If keepalives are being used, several parameters may be controlled using the following options:

-k n: The argument n specifies the time (in seconds) that a connection must be idle before the first keepalive probe will be sent.
-K n: The argument n specifies the interval (in seconds) between keepalive probes if no response is received.
-N n: The argument n specifies the number of unanswered keepalive probes that will be sent prior to dropping the connection.

The default keepalive values corresponding to these options are controlled by the parameters tcp_keepidle (7200 seconds), tcp_keepintvl (75 seconds), and tcp_nkeep (8). These can be tuned on a system-wide basis using inconfig(ADMN). These options exist solely to provide finer control of keepalives on a per-application basis.

Authenticated telnet using Kerberos

Authentication takes place between the requesting principal and the host principal where the telnetd daemon is running using the network credentials of the user that invoked telnet(TC). The principal name for host machine.subdomain.domain is

   host/machine.subdomain.domain

The machine name must be fully qualified (for example, kvetch.your_company.com). The service key for this host principal is cached in the local Default Service Key Table (/krb5/v5srvtab), and must match the service key stored in the Security Registry.

The following authentication options are supported:

-a argument

The following arguments control authentication:

debug: Turn on authentication debugging.
off: Turn off authentication.
valid: Relaxed authentication mode; if both authentication and authorization succeed, telnet does not prompt for a password. If authentication succeeds but authorization fails, telnet prompts the user for their login and password.

-R

Strict authentication mode; authentication must succeed or the login is refused.

-v

Equivalent to -a valid.

-X atype

Disable authentication type atype. Currently, the only type supported is KERBEROS_V5.

For authorization to succeed, the principal name of the user must exist in the $HOME/.k5login file on the machine which they are trying to log into (this file must be writable only by the user or by root, and it must be readable by root on the filesystem where it resides).

Limitations

Some TELNET commands are only partially implemented.

Because of bugs in the original 4.2 BSD version of telnet, telnetd performs some unreliable protocol exchanges to try to discover if the remote client is, in fact, a 4.2 BSD telnet.

Binary mode has no common interpretation except between similar operating systems (UNIX in this case).

The terminal type name received from the remote client will be converted into lowercase.

telnetd never sends TELNET go ahead commands.

Authentication is based on Version 5 of the Kerberos Network Authentication Service protocol. Only this version of the protocol is supported.

Data encryption is not supported.

Files

/etc/inetd.conf: configuration file for inetd
/etc/issue: default banner file
/etc/services: Internet services list
/krb5/v5srvtab: local default service key table
$HOME/.k5login: access control file for the SCO Secure TCP/IP Utilities

Standards conformance

telnetd is not part of any currently supported standard. It is an extension of AT&T UNIX System V provided by The Santa Cruz Operation, Inc.

telnetd is conformant with:
RFC 727, RFC 854 (STD 8), RFC 856 (STD 27) RFC 857 (STD 28), RFC 859 (STD 30), RFC 860 (STD 31), RFC 885, RFC 1079, RFC 1080, RFC 1091, RFC 1096, RFC 1123