Tribblix: manual page: telnetd.8

IN.TELNETD(8) Maintenance Commands and Procedures IN.TELNETD(8)

NAME

in.telnetd, telnetd - DARPA TELNET protocol server

SYNOPSIS

/usr/sbin/in.telnetd [-a authmode] [-EXUh] [-s tos]
[-S keytab] [-M realm]

DESCRIPTION

in.telnetd is a server that supports the DARPA standard TELNET
virtual terminal protocol. in.telnetd is normally invoked in the
internet server (see inetd(8)), for requests to connect to the TELNET
port as indicated by the /etc/services file (see services(5)).

in.telnetd operates by allocating a pseudo-terminal device for a
client, then creating a login process which has the subsidiary side
of the pseudo-terminal as its standard input, output, and error.
in.telnetd manipulates the manager side of the pseudo-terminal,
implementing the TELNET protocol and passing characters between the
remote client and the login process.

When a TELNET session starts up, in.telnetd sends TELNET options to
the client side indicating a willingness to do remote echo of
characters, and to suppress go ahead. The pseudo-terminal allocated
to the client is configured to operate in "cooked" mode, and with
XTABS, ICRNL and ONLCR enabled. See termio(4I).

in.telnetd is willing to do: echo, binary, suppress go ahead, and
timing mark. in.telnetd is willing to have the remote client do:
binary, terminal type, terminal size, logout option, and suppress go
ahead.

in.telnetd also allows environment variables to be passed, provided
that the client negotiates this during the initial option
negotiation. The DISPLAY environment variable may be sent this way,
either by the TELNET general environment passing methods, or by means
of the XDISPLOC TELNET option. DISPLAY can be passed in the
environment option during the same negotiation where XDISPLOC is
used. Note that if you use both methods, use the same value for
both. Otherwise, the results may be unpredictable.

These options are specified in Internet standards RFC 1096, RFC 1408,
RFC 1510, RFC 1571, RFC 2941, RFC 2942, RFC 2946, and RFC 1572. The
following Informational draft is also supported: RFC 2952.

The banner printed by in.telnetd is configurable. The default is
(more or less) equivalent to `uname -sr` and will be used if no
banner is set in /etc/default/telnetd. To set the banner, add a line
of the form

BANNER="..."

to /etc/default/telnetd. Nonempty banner strings are fed to shells
for evaluation. The default banner may be obtained by

BANNER="\\r\\n\\r\\n`uname -s` `uname -r`\\r\\n\\r\\n"

and no banner will be printed if /etc/default/telnetd contains

BANNER=""

OPTIONS

The following options are supported:

-a authmode
This option may be used for specifying what mode
should be used for authentication. There are several
valid values for authmode:

valid
Only allows connections when the remote user
can provide valid authentication information
to identify the remote user, and is allowed
access to the specified account without
providing a password.

user
Only allows connections when the remote user
can provide valid authentication information
to identify the remote user. The login(1)
command will provide any additional user
verification needed if the remote user is not
allowed automatic access to the specified
account.

none
This is the default state. Authentication
information is not required. If no or
insufficient authentication information is
provided, then the login(1) program provides
the necessary user verification.

off
This disables the authentication code. All
user verification happens through the
login(1) program.

-E
Disables encryption support negotiation.

-h
Disables displaying host specific information before
login has been completed.

-M realm
Uses the indicated Kerberos V5 realm. By default, the
daemon will determine its realm from the settings in
the krb5.conf(5) file.

-s tos
Sets the IP TOS option.

-S keytab
Sets the KRB5 keytab file to use. The
/etc/krb5/krb5.keytab file is used by default.

-U
Refuses connections that cannot be mapped to a name
through the getnameinfo(3SOCKET) function.

-X
Disables Kerberos V5 authentication support
negotiation.

USAGE

telnetd and in.telnetd are IPv6-enabled. See ip6(4P).

SECURITY

in.telnetd can authenticate using Kerberos V5 authentication,
pam(3PAM), or both. By default, the telnet server will accept valid
Kerberos V5 authentication credentials from a telnet client that
supports Kerberos. in.telnetd can also support an encrypted session
from such a client if the client requests it.

The telnet protocol only uses single DES for session
protection--clients request service tickets with single DES session
keys. The KDC must know that host service principals that offer the
telnet service support single DES, which, in practice, means that
such principals must have single DES keys in the KDC database.

In order for Kerberos authentication to work, a host/<FQDN> Kerberos
principal must exist for each Fully Qualified Domain Name associated
with the telnetd server. Each of these host/<FQDN> principals must
have a keytab entry in the /etc/krb5/krb5.keytab file on the telnetd
server. An example principal might be:

host/bigmachine.eng.example.com

See kadmin(8) for instructions on adding a principal to a krb5.keytab
file. See for a discussion of Kerberos authentication.

in.telnetd uses pam(3PAM) for authentication, account management,
session management, and password management. The PAM configuration
policy, listed through /etc/pam.conf, specifies the modules to be
used for in.telnetd. Here is a partial pam.conf file with entries for
the telnet command using the UNIX authentication, account management,
session management, and password management modules.

telnet auth requisite pam_authtok_get.so.1
telnet auth required pam_dhkeys.so.1
telnet auth required pam_unix_auth.so.1

telnet account requisite pam_roles.so.1
telnet account required pam_projects.so.1
telnet account required pam_unix_account.so.1

telnet session required pam_unix_session.so.1

telnet password required pam_dhkeys.so.1
telnet password requisite pam_authtok_get.so.1
telnet password requisite pam_authtok_check.so.1
telnet password required pam_authtok_store.so.1

If there are no entries for the telnet service, then the entries for
the "other" service will be used. If multiple authentication modules
are listed, then the user may be prompted for multiple passwords.

For a Kerberized telnet service, the correct PAM service name is
ktelnet.

FILES

/etc/default/telnetd

NOTES

Some TELNET commands are only partially implemented.

Binary mode has no common interpretation except between similar
operating systems.

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

The packet interface to the pseudo-terminal should be used for more
intelligent flushing of input and output queues.

in.telnetd never sends TELNET go ahead commands.

The pam_unix(7) module is no longer supported. Similar functionality
is provided by pam_authtok_check(7), pam_authtok_get(7),
pam_authtok_store(7), pam_dhkeys(7), pam_passwd_auth(7),
pam_unix_account(7), pam_unix_auth(7), and pam_unix_session(7).

The in.telnetd service is managed by the service management facility,
smf(7), under the service identifier:

svc:/network/telnet

Administrative actions on this service, such as enabling, disabling,
or requesting restart, can be performed using svcadm(8).
Responsibility for initiating and restarting this service is
delegated to inetd(8). Use inetadm(8) to make configuration changes
and to view configuration information for this service. The service's
status can be queried using the svcs(1) command.

May 21, 2022 IN.TELNETD(8)