in.telnetd man page on OpenIndiana

Man page or keyword search:  
man Server   20441 pages
apropos Keyword Search (all sections)
Output format
OpenIndiana logo
[printable version]

in.telnetd(1M)		System Administration Commands		in.telnetd(1M)

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(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 tim‐
       ing 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 val‐
		      ues 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 auto‐
			       matic access to the specified account.

		      none     This  is	 the  default  state.	Authentication
			       information  is not required. If no or insuffi‐
			       cient authentication information	 is  provided,
			       then  the  login(1) program provides the neces‐
			       sary user verification.

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

       -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 sup‐
       ports 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 sin‐
       gle DES, which, in practice, means that such principals must have  sin‐
       gle 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(1M) or gkadmin(1M) 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,  ses‐
       sion 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 man‐
       agement, and password management modules.

	 telnet	 auth requisite		 pam_authtok_get.so.1
	 telent	 auth required		 pam_dhkeys.so.1
	 telent	 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

       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 ktel‐
       net.

FILES
       /etc/default/telnetd

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

       ┌─────────────────────────────┬─────────────────────────────┐
       │      ATTRIBUTE TYPE	     │	    ATTRIBUTE VALUE	   │
       ├─────────────────────────────┼─────────────────────────────┤
       │Availability		     │service/network/telnet	   │
       └─────────────────────────────┴─────────────────────────────┘

SEE ALSO
       login(1), svcs(1), telnet(1), gkadmin(1M), inetadm(1M), inetd(1M), kad‐
       min(1M),	  svcadm(1M),	pam(3PAM),   getnameinfo(3SOCKET),   issue(4),
       krb5.conf(4),  pam.conf(4),   services(4),   attributes(5),   pam_auth‐
       tok_check(5),  pam_authtok_get(5), pam_authtok_store(5), pam_dhkeys(5),
       pam_passwd_auth(5),	 pam_unix_account(5),	     pam_unix_auth(5),
       pam_unix_session(5), smf(5), ip6(7P), termio(7I)

       Alexander,  S. RFC 1572, TELNET Environment Option. Network Information
       Center, SRI International, Menlo Park, Calif., January 1994.

       Borman, Dave. RFC 1408, TELNET Environment Option. Network  Information
       Center, SRI International, Menlo Park, Calif., January 1993.

       Borman,	Dave.  RFC  1571,  TELNET  Environment Option Interoperability
       Issues. Network Information  Center,  SRI  International,  Menlo	 Park,
       Calif., January 1994.

       Crispin,	 Mark. RFC 727, TELNET Logout Option. Network Information Cen‐
       ter, SRI International, Menlo Park, Calif., April 1977.

       Marcy, G. RFC 1096, TELNET X Display Location Option. Network  Informa‐
       tion Center, SRI International, Menlo Park, Calif., March 1989.

       Postel,	Jon,  and  Joyce Reynolds. RFC 854, TELNET Protocol Specifica‐
       tion.  Network  Information  Center,  SRI  International,  Menlo	 Park,
       Calif., May 1983.

       Waitzman,  D.  RFC 1073, TELNET Window Size Option. Network Information
       Center, SRI International, Menlo Park, Calif., October 1988.

       Kohl, J., Neuman, C., The Kerberos Network Authentication Service (V5),
       RFC 1510. September 1993.

       Ts'o, T. and J. Altman, Telnet Authentication Option, RFC 2941. Septem‐
       ber 2000.

       Ts'o, T., Telnet Authentication: Kerberos Version 5, RFC 2942.  Septem‐
       ber 2000.

       Ts'o, T., Telnet Data Encryption Option, RFC 2946. September 2000.

       Ts'o, T., Telnet Encryption: DES 64 bit Cipher Feedback, RFC 2952. Sep‐
       tember 2000.

NOTES
       Some TELNET commands are only partially implemented.

       Binary mode has no common interpretation except between similar operat‐
       ing 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(5)	 module is no longer supported.. Similar functionality
       is  provided  by	 pam_authtok_check(5),	pam_authtok_get(5),  pam_auth‐
       tok_store(5),  pam_dhkeys(5),  pam_passwd_auth(5), pam_unix_account(5),
       pam_unix_auth(5), and pam_unix_session(5).

       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.

SunOS 5.11			  10 Nov 2005			in.telnetd(1M)
[top]

List of man pages available for OpenIndiana

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net