Synopsis

in.telnetd

, telnetd

- DARPA TELNET protocol server

/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(1M)), for requests to connect to the TELNET port as indicated by the /etc/services file (see services(4)).

in.telnetd operates by allocating a pseudo-terminal device for a client, then creating a login process which has the slave side of the pseudo-terminal as its standard input, output, and error. in.telnetd manipulates the master 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(7I).

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(4) 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(7P).

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

If Kerberized telnet(1) must be used, allow_weak_keys = true must be set in krb5.conf(4) on all systems involved (KDC, client, and server), as DES is hardcoded into the protocol.

See kadmin(1M) or gkadmin(1M) for instructions on adding a principal to a krb5.keytab file. See Oracle Solaris 11.1 Administration: Security Services for a discussion of Kerberos authentication.

in.telnetd uses pam(3PAM) for authentication, account management, session management, and password management. The PAM configuration policy, configured in /etc/pam.conf or per-service files in /etc/pam.d/, 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
telent  password requisite      pam_authtok_get.so.1
telnet  password requisite      pam_authtok_check.so.1
telnet  password required       pam_authtok_store.so.1

The equivalent PAM configuration using /etc/pam.d/ would be the following entries in /etc/pam.d/telnet:

auth requisite         pam_authtok_get.so.1
auth required          pam_dhkeys.so.1
auth required          pam_unix_auth.so.1
account requisite       pam_roles.so.1
account required               pam_projects.so.1
account required               pam_unix_account.so.1

session required               pam_unix_session.so.1

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

If there are no entries for the telnet service in /etc/pam.conf and /etc/pam.d/telnet does not exist, then the entries for the “other” service in /etc/pam.conf will be used. If there are not any entries in /etc/pam.conf for the “other” service then the entries in /etc/pam.d/other 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

Attributes

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	service/network/telnet

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 in.telnetd service is managed by the service management facility, smf(5), under the service identifier:

svc:/network/telnet

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

Skip Navigation Links
Exit Print View
	man pages section 1M: System Administration Commands Oracle Solaris 11.1 Information Library