TELNET protocol server
[ -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 ]
The telnetd command is a server which supports
the Internet standard TELNET virtual terminal
protocol; telnetd is invoked by the Internet
normally for requests to connect to the TELNET port
as indicated by the /etc/services file (see
The -debug option can be used to start up
telnetd manually, instead of through
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
is specified as
no banner file will be displayed.
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:
use only the specified pty number, ptynum
use ptys starting at pty number low
use ptys from 0 through pty number high
use ptys in the specified range
The -r option is generally useful in the following
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:
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.
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.
Exercise client (not currently implemented).
Display the received data stream.
Print information about the negotiation of the
Display data passed to the pseudo-terminal.
Print the options information, as well as some
additional information about what processing is going on.
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
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.
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.
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:
The default keepalive values corresponding to these options
are controlled by the parameters
tcp_keepidle (7200 seconds),
tcp_keepintvl (75 seconds), and
These can be tuned on a system-wide basis using
These options exist solely to provide finer control of
keepalives on a per-application basis.
The argument n
specifies the time (in seconds) that a connection must be idle
before the first keepalive probe will be sent.
The argument n
specifies the interval (in seconds) between keepalive probes if
no response is received.
The argument n
specifies the number of unanswered keepalive probes that will be
sent prior to dropping the connection.
Authenticated telnet using Kerberos
Authentication takes place between the
and the host principal where the
telnetd daemon is running
using the network credentials of the user that
The principal name for host
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:
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).
The following arguments control authentication:
Turn on authentication debugging.
Turn off authentication.
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.
Strict authentication mode;
authentication must succeed or the login is refused.
Equivalent to -a valid.
Disable authentication type atype. Currently, the only type
supported is KERBEROS_V5.
Some TELNET commands are only partially
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
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.
configuration file for inetd
default banner file
Internet services list
local default service key table
access control file for the SCO Secure TCP/IP Utilities
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 854 (STD 8),
RFC 856 (STD 27)
RFC 857 (STD 28),
RFC 859 (STD 30),
RFC 860 (STD 31),
© 2004 The SCO Group, Inc. All rights reserved.