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 key-
     tab] [-M realm]

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

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

     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  infor-
                                     mation   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  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
                                     verification.



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

     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 Kerberized telnet service, the correct PAM service  name
     is "ktelnet".

FILES
     /etc/default/telnetd



ATTRIBUTES

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

     ____________________________________________________________
    |       ATTRIBUTE TYPE        |       ATTRIBUTE VALUE       |
    |_____________________________|_____________________________|
    | Availability                | SUNWtnetd                   |
    |_____________________________|_____________________________|


SEE ALSO
     login(1),  svcs(1),   telnet(1),   inetadm(1M),   inetd(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)

     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 Interna-
     tional, Menlo Park, Calif., January 1994.

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

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

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

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

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