Provided by: krb5-rsh-server_1.0.1-1_amd64 bug


       kshd - kerberized remote shell server


       kshd [ -kr45ec ] [-D port] [-L variable]


       Krshd  is  the  server  for the rcmd(3) routine and, consequently, for the rsh(1) program.
       The server provides remote execution facilities with authentication  based  on  privileged
       port numbers from trusted hosts or the Kerberos authentication system.

       The  kshd  server  is  invoked  by  inetd(8c)  when  it  receives a connection on the port
       indicated in /etc/inetd.conf.  A typical  /etc/inetd.conf  configuration  line  for  krshd
       might be:

       kshell    stream    tcp  nowait    root /usr/sbin/kshd kshd -5c

       When a service request is received, the following protocol is initiated:

       1)     Authentication is checked

       2)     Check authorization via the access-control files .k5login and .klogin in the user's
              home directory.

       3)     A null byte is returned on the initial socket and the command line is passed to the
              normal  login  shell  of  the  user.   The  shell  inherits the network connections
              established by krshd.

              Krshd can be configured  by command-line arguments passed by inetd(8).
               The options are:

       -5        Allow Kerberos5 authentication with the  .k5login  access  control  file  to  be
                 trusted.   If  this  authentication  system  is  used  by  the  client  and  the
                 authorization check is passed, then the user is allowed to log in.  If the  user
                 has  no  .k5login  file,  the  login  will  be  authorized  if  the  results  of
                 krb5_aname_to_localname conversion matches the  account  name.   Unless  special
                 rules are configured, this will be true if and only if the Kerberos principal of
                 the connecting user is in the default local  realm  and  the  principal  portion
                 matches the account name.

       -4        Allow  Kerberos4  authentication  with  the  .klogin  access  control file to be
                 trusted.   If  this  authentication  system  is  used  by  the  client  and  the
                 authorization check is passed, then the user is allowed to log in.

       -k        Allow  Kerberos5 and Kerberos4 as acceptable authentication mechanisms.  This is
                 the same as including -4 and -5.

       -e        Require the client to encrypt the connection.  Only  Kerberos5  clients  support

       -L variable
                 Carry  through  the current value of the specified variable into the environment
                 of the child.  This option can be used to preserve up to four variables.

       -c        Require Kerberos5  clients  to  present  a  cryptographic  checksum  of  initial
                 connection  information  like  the name of the user that the client is trying to
                 access in the initial authenticator.  This checksum provides additionl  security
                 by  preventing an attacker from changing the initial connection information.  To
                 benefit from this security, only Kerberos5  should  be  trusted;  Kerberos4  and
                 rhosts  authentication  do  not  include  this  checksum.   If  this  option  is
                 specified,  older  Kerberos5  clients  that  do  not  send  a  checksum  in  the
                 authenticator  will  not be able to authenticate to this server.  This option is
                 mutually exclusive with the -i option.

                      If neither the -c or -i options are specified,then checksums are  validated
                 if  presented.  Since it is difficult to remove a checksum from an authenticator
                 without making the  authenticator  invalid,  this  default  mode  is  almost  as
                 significant of a security improvement as -c if new clients are used.  It has the
                 additional   advantage   of   backwards   compatability   with   some   clients.
                 Unfortunately, clients before Kerberos V5, Beta5, generate invalid checksums; if
                 these clients are used, the -i option must be used.

       -i        Ignore authenticator checksums if provided.  This  option  ignore  authenticator
                 checksusm  presented  by  current Kerberos clients to protect initial connection
                 information; it is the opposite of -c.  This option  is  provided  because  some
                 older clients -- particularly clients predating the release of Kerberos V5 Beta5
                 (May 1995) -- present bogus checksums that prevent Kerberos authentication  from
                 succeeding in the default mode.

       Krshd supports six options which may be used for testing:

       -S keytab Set the keytab file to use.

       -M realm  Set the Kerberos realm to use.

       -A        Don't allocate a reserved port for the stderr connection.

       -P path   Use the argument to find the Kerberos binaries.  Normally a compiled in argument
                 is used.

       -D port   Run in standalone mode, listening on port.   The  daemon  will  exit  after  one
                 connection and will not background itself.

       -w [ip|maxhostlen[,[no]striplocal]]
                 Controls  the  form  of  the  remote hostname passed to login(1).  Specifying ip
                 results in the numeric IP address always being passed to login(1).  Specifying a
                 number,  maxhostlen,  sets the maximum length of the hostname passed to login(1)
                 before it will be passed as a numeric IP address.  If maxhostlen is 0, then  the
                 system  default,  as  determined  by the utmp or utmpx structures, is used.  The
                 nostriplocal and striplocal options, which must be preceded by a comma,  control
                 whether  or  not the local host domain is stripped from the remote hostname.  By
                 default, the equivalent of striplocal is in effect.


       Except for the last one listed below, all diagnostic messages are returned on the  initial
       socket,  after  which  any  network  connections  are  closed.  An error is indicated by a
       leading byte with a value of 1 (0 is returned in step 3 above upon  successful  completion
       of all the steps prior to the execution of the login shell).

       ``locuser too long''
       The name of the user on the client's machine is longer than 16 characters.

       ``remuser too long''
       The name of the user on the remote machine is longer than 16 characters.

       ``command too long ''
       The  command  line  passed  exceeds  the size of the argument list (as configured into the

       ``Login incorrect.''
       No password file entry for the user name existed.

       ``No remote directory.''
       The chdir command to the home directory failed.

       ``Permission denied.''
       The authentication procedure described above failed.

       ``Can't make pipe.''
       The pipe needed for the stderr, wasn't created.

       ``Try again.''
       A fork by the server failed.

       ``<shellname>: ...''
       The user's login shell could not be started.  This message is returned on  the  connection
       associated with the stderr, and is not preceded by a flag byte.


       rshd(8), rsh(1), rcmd(3)


       A facility to allow all data exchanges to be encrypted should be present.

       A more extensible protocol should be used.