DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH
 

telnetd(ADMN)


telnetd -- TELNET protocol server

Syntax

/etc/telnetd [ -a debug | off | valid ] [ -b banner_file | none ] [ -debug ]
[ -D exercise | netdata | options | ptydata | report ] [ -h ]
[ -r pty ] [ -k n ] [ -K n ] [ -N n ] [ -n ] [ -R ] [ -v ] [ -X atype ] [ port ]

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:

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:

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 (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

See also

iknt(ADMP), inconfig(ADMN), inetd(ADMN), inetd.conf(SFF), services(SFF), telnet(TC)

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


© 2004 The SCO Group, Inc. All rights reserved.