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