rshd man page on DigitalUNIX

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

rshd(8)								       rshd(8)

NAME
       rshd - The remote shell server daemon

SYNOPSIS
       rshd [-aelnxK]

OPTIONS
       The  addresses  for the hostname are requested, verifying that the name
       and address correspond.	 Causes	 rshd  to  check  for  the  /etc/nolo‐
       gin_hostname and /etc/nologin files.  If either exists, rshd prints its
       contents and exits.  Prevents the ruserok command from doing any	 vali‐
       dation  based  on  the  user's  file, unless the user is the root user.
       Disables	 transport-level,  keep-alive  messages.   Encrypts  the  data
       transmitted  between  the  local	 host and the remote host. This option
       requires that the local and remote hosts be configured to use  Kerberos
       authentication in the same or trusting Kerberos realms.

	      If  the  rshd daemon is started with the -x option, only connec‐
	      tions initiated with the -x option from a remote	host  will  be
	      accepted.	  All  communications  between	the  two hosts will be
	      encrypted.  Specifies that only Kerberos	authenticated  connec‐
	      tions  will be accepted. This option requires that the local and
	      remote hosts be configured to use Kerberos authentication in the
	      same or trusting Kerberos realms.

	      If  the  rshd daemon is started with the -K option, only connec‐
	      tions initiated from a host in the  same	or  trusting  Kerberos
	      domain  will  be	accepted.  All	communications between the two
	      hosts will be encrypted.

DESCRIPTION
       The rshd daemon is the server for  the  rcmd(3)	routine	 and  for  the
       rsh(1)  program.	 The  server provides remote execution facilities with
       authentication based on privileged port numbers from trusted hosts.

       The rshd daemon listens for service requests at the port	 indicated  in
       the cmd service specification; see services(4).	When a service request
       is received, the following protocol is initiated: The server checks the
       client's	 source port. If the port is not in the range 512 to 1023, the
       server aborts the connection.  The server reads bytes from  the	socket
       up  to  a  null (`\0') byte.  The resultant string is interpreted as an
       ASCII number, base 10.  If the number received in step 2 is nonzero, it
       is  interpreted as the port number of a secondary stream to be used for
       the stderr option. A second connection is then created to the specified
       port  on	 the client's machine.	The source port of this second connec‐
       tion is also in the range 512 to 1023.  The server checks the  client's
       source  address	and  requests the corresponding hostname (see gethost‐
       byaddr(3), hosts(4), and named(8)). If the hostname  cannot  be	deter‐
       mined,  the dot-notation representation of the host address is used. If
       the hostname is in the same domain as the server (according to the last
       two  components	of the domain name), or if the -a option is given, the
       addresses for the hostname are requested, verifying that the  name  and
       address	correspond.  If	 address verification fails, the connection is
       aborted with the message	 Host  address	mismatch.   A  null-terminated
       username	 of at most 16 bytes is retrieved on the initial socket.  This
       username is interpreted as the user identity on the client 's  machine.
       A null-terminated username of at most 16 bytes is retrieved on the ini‐
       tial socket.  This username is interpreted as a user identity to use on
       the  server's  machine.	 A  null-terminated  command to be passed to a
       shell is retrieved on the initial socket.  The length of the command is
       limited	by  the upper bound on the size of the system's argument list.
       The rshd daemon then validates the user.	 The way  in  which  the  rshd
       daemon  authenticates a user and transmits data depends on if the local
       and remote hosts are using a basic connection or	 a  secure  connection
       (Kerberos).  Basic  and secure connections provide user authentication,
       however a secure connection also provides client and server authentica‐
       tion, data encryption, data integrity, and nonrepudiation.  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 connec‐
       tions established by rshd.

       Transport-level, keep-alive messages are enabled unless the  -n	option
       is  present. The use of keep-alive messages allows sessions to be timed
       out if the client crashes or becomes unreachable.

   Basic Connection
       A basic connection is one where the  rshd  daemon  validates  the  user
       using  ruserok(3),  which  uses	the file /etc/hosts.equiv and the file
       found in the user's home directory.  The -l option prevents  ruserok(3)
       from  doing any validation based on the user's file, unless the user is
       the superuser.

       If rshd was started with the -e option, the user is not the  superuser,
       and  either the /etc/nologin_hostname or /etc/nologin file exists, rshd
       prints the contents of the first file found and aborts the  connection.
       If the file has a zero length, rshd prints a logins disabled message.

   Secure Connection
       A  secure  connection is one where the rshd daemon authenticates a user
       by using Kerberos. Kerberos is a client/server application that authen‐
       ticate  the  client,  server,  and  user; encrypt data; and ensure data
       integrity and nonrepudiation.  See your system administrator to	deter‐
       mine  if	 your  system is running Kerberos. See Security Administration
       for more information about Kerberos.

       Kerberos authenticates by using	secret-key  cryptography  and  tickets
       between	Kerberos  clients  and Kerberos server in the same or trusting
       Kerberos realms. Once authenticated by Kerberos, users receive  a  Ker‐
       beros  Ticket  Granting	Ticket	(TGT).	Users with a valid TGT are not
       prompted for a username or password when the remote host is in the same
       or trusting Kerberos realm.

       Alternatively,  you can configure the rsh, rlogin, and rcp commands and
       applications that use the rcmd function to automatically use  a	Secure
       Shell  connection by enabling the Secure Shell EnforceSecureRutils key‐
       word   in   the	 /etc/ssh2/ssh2_config	 file	or   in	   a	user's
       $HOME/.ssh2/ssh2_config	file.  When the EnforceSecureRutils keyword is
       enabled: The rsh command can  use  only	host-based  authentication  to
       authenticate  users.  Secure  Shell  host-based authentication uses the
       file as described in Basic Connection,  but  also  requires  additional
       configuration as described in Security Administration.  The sshd daemon
       runs and spawns the srcmd child process; the rshd and  rlogind  daemons
       do not run.

       See  Security  Administration  for  more information about Secure Shell
       authentication and the EnforceSecureRutils keyword.

       After it is determined that Secure Shell will be used, all  authentica‐
       tion  and  communication	 between  the  client  and server will use the
       Secure Shell connection. A connection is not established if a user can‐
       not be authenticated.

DIAGNOSTICS
       Except  for the last diagnostic message listed, 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 9 above upon successful completion  of  all  the
       steps prior to the execution of the login shell).  The name of the user
       on the client's machine is longer than 16 characters.  The name of  the
       user  on	 the remote machine is longer than 16 characters.  The command
       line passed exceeds the size of the argument list (as  configured  into
       the  system).   No  password  file entry for the username existed.  The
       server is currently not accepting connections.  The  chdir  command  to
       the  home  directory  failed.   The authentication procedure previously
       described failed.  The pipe needed for the stderr option,  but  it  was
       not  created.   A  fork	by  the server failed.	The user's login shell
       could not be started.  This message is returned on the connection asso‐
       ciated  with  the  stderr option, and is not preceded by a option byte.
       An attempt was made to start rshd using the -K flag without first  con‐
       figuring the system as part of a Kerberos realm or domain.

FILES
       Specifies  the  command path Stops logins.  In a cluster, there is also
       /etc/nologin_hostname.  Specifies  Secure  Shell	 client	 configuration
       information.

SEE ALSO
       Commands:  kinit(1),  kdestroy(1), klist(1), rcp(1), rlogin(1), rsh(1),
       ssh2(1)

       Functions: rcmd(3), ruserok(3)

       Files: hosts.equiv(4), rhosts(4), ssh2_config(4)

       Guides: Security Administration

								       rshd(8)
[top]

List of man pages available for DigitalUNIX

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