Unix‎ > ‎Solaris‎ > ‎Solaris man pages‎ > ‎1m‎ > ‎


     in.telnetd, telnetd - DARPA TELNET protocol server

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

     in.telnetd is a server that supports the DARPA standard TEL-
     NET   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

     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 sup-
     ported: 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


     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  con-


     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  infor-
                                     mation   to   identify   the
                                     remote user, and is  allowed
                                     access   to   the  specified
                                     account without providing  a

                     user            Only allows connections when
                                     the  remote user can provide
                                     valid authentication  infor-
                                     mation   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

                     off             This disables the  authenti-
                                     cation code. All user verif-
                                     ication happens through  the
                                     login(1) program.

     -E              Disables encryption support negotiation.

     -h              Disables displaying host  specific  informa-
                     tion 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

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

     -X              Disables Kerberos V5 authentication  support

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

     in.telnetd can authenticate using  Kerberos  V5  authentica-
     tion, 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:


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

     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
     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 ktelnet.


     See attributes(5) for descriptions of the  following  attri-

    |       ATTRIBUTE TYPE        |       ATTRIBUTE VALUE       |
    | Availability                | SUNWtnetd                   |

     login(1),  svcs(1),  telnet(1),  gkadmin(1M),   inetadm(1M),
     inetd(1M),      kadmin(1M),      svcadm(1M),      pam(3PAM),
     getnameinfo(3SOCKET), issue(4),  krb5.conf(4),  pam.conf(4),
     services(4),       attributes(5),      pam_authtok_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)

     System Administration Guide: Security Services

     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 Interoper-
     ability    Issues.    Network    Information   Center,   SRI
     International, Menlo Park, Calif., January 1994.

     Crispin, Mark. RFC 727, TELNET Logout Option. Network Infor-
     mation  Center, SRI International, Menlo Park, Calif., April

     Marcy, G. RFC 1096, TELNET X Display Location  Option.  Net-
     work  Information  Center,  SRI  International,  Menlo Park,
     Calif., March 1989.

     Postel, Jon, and Joyce Reynolds. RFC  854,  TELNET  Protocol
     Specification.  Network  Information  Center,  SRI  Interna-
     tional, 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. September 2000.

     Ts'o, T., Telnet Authentication:  Kerberos  Version  5,  RFC
     2942. September 2000.

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

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

     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(5) module  is  no  longer  supported..  Similar
     functionality    is    provided   by   pam_authtok_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),
     and pam_unix_session(5).
     The in.telnetd service is managed by the service  management
     facility, smf(5), under the service identifier:


     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  infor-
     mation for this service. The service's status can be queried
     using the svcs(1) command.

Man pages from Solaris 10 Update 8. See docs.sun.com and www.oracle.com for further documentation and Solaris information.