Unix/Linux Go Back    

OpenSolaris 2009.06 - man page for remote_shell (opensolaris section 1)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)

rsh(1)					  User Commands 				   rsh(1)

       rsh, remsh, remote_shell - remote shell

       rsh [-n] [-a] [-K] [-PN | -PO] [-x] [-f | -F] [-l username]
	    [-k realm] hostname command

       rsh hostname [-n] [-a] [-K] [-PN | -PO] [-x] [-f | -F]
	    [-l username] [-k realm] command

       remsh [-n] [-a] [-K] [-PN | -PO] [-x] [-f | -F] [-l username]
	    [-k realm] hostname command

       remsh hostname [-n] [-a] [-K] [-PN | -PO] [-x] [-f | -F]
	    [-l username] [-k realm] command

	hostname [-n] [-a] [-PN | -PO] [-x] [-f | -F]
	    [-l username] [-k realm] command

       The rsh utility connects to the specified hostname and executes the specified command. rsh
       copies its standard input to the remote command, the standard output of the remote command
       to  its	standard  output,  and	the  standard error of the remote command to its standard
       error. Interrupt, quit, and terminate signals are propagated to the  remote  command.  rsh
       normally terminates when the remote command does.

       The  user  can  opt for a secure session of rsh which uses Kerberos V5 for authentication.
       Encryption of the network session traffic is also possible. The rsh session can be kerber-
       ized  using  any of the following Kerberos specific options: -a, -PN or -PO, -x, -f or -F,
       and -k realm. Some of these options (-a, -x, -PN or -PO, and -f or -F) can also be  speci-
       fied  in  the  [appdefaults]  section  of krb5.conf(4). The usage of these options and the
       expected behavior is discussed in the OPTIONS section below. If Kerberos authentication is
       used,  authorization  to the account is controlled by rules in krb5_auth_rules(5). If this
       authorization fails, fallback to normal rsh using rhosts occurs only if the -PO option  is
       used explicitly on the command line or is specified in krb5.conf(4). Also, the -PN or -PO,
       -x, -f or -F, and -k realm options are just supersets of the -a option.

       If you omit command, instead of executing a single command, rsh logs you in on the  remote
       host using rlogin(1).

       rsh does not return the exit status code of command.

       Shell  metacharacters  which  are  not  quoted are interpreted on the local machine, while
       quoted metacharacters are interpreted on the remote machine. See EXAMPLES.

       If there is no locale setting in the initialization file of the login shell (.cshrc,  .	.
       .)  for	a  particular  user, rsh always executes the command in the "C" locale instead of
       using the default locale of the remote machine.

       The command is sent unencrypted to the remote system. All subsequent network session traf-
       fic is encrypted. See -x.

       The following options are supported:

       -a	      Explicitly  enable Kerberos authentication and trusts the .k5login file for
		      access-control. If the authorization check by in.rshd(1M)  on  the  server-
		      side  succeeds and if the .k5login file permits access, the user is allowed
		      to carry out the command.

       -f	      Forward a copy of the local credentials (Kerberos Ticket	Granting  Ticket)
		      to  the  remote  system.	This is a non-forwardable ticket granting ticket.
		      Forward a ticket granting ticket if you need to  authenticate  yourself  to
		      other  Kerberized  network services on the remote host. An example would be
		      if your home directory on the remote host is NFS mounted by way of Kerberos
		      V5.  If  your  local credentials are not forwarded in this case, you cannot
		      access your home directory. This option is mutually exclusive with  the  -F

       -F	      Forward a forwardable copy of the local credentials (Kerberos Ticket Grant-
		      ing Ticket) to the remote system. The -F option provides a superset of  the
		      functionality  offered  by  the -f option. For example, with the -f option,
		      if, after you connected to the remote host, your remote  command	attempted
		      to  invoke /usr/bin/ftp, /usr/bin/telnet, /usr/bin/rlogin, or /usr/bin/rsh,
		      with the -f or -F options, the attempt  would  fail.  Thus,  you	would  be
		      unable  to  push	your single network sign on trust beyond one system. This
		      option is mutually exclusive with the -f option.

       -k realm       Causes rsh to obtain tickets for the remote host in realm  instead  of  the
		      remote host's realm as determined by krb5.conf(4).

       -K	      This  option explicitly disables Kerberos authentication. It can be used to
		      override the autologin variable in krb5.conf(4).

       -l username    Uses username as the remote username instead of your local username. In the
		      absence of this option, the remote username is the same as your local user-

       -n	      Redirect the input of rsh to /dev/null. You sometimes need this  option  to
		      avoid  unfortunate interactions between rsh and the shell which invokes it.
		      For example, if you are running rsh and invoke  a  rsh  in  the  background
		      without  redirecting its input away from the terminal, it blocks even if no
		      reads are posted by the remote command. The -n option prevents this.

       -PO	      Explicitly request new (-PN) or old (-PO) version of  the  Kerberos  "rcmd"
       -PN	      protocol.  The  new protocol avoids many security problems prevalant in the
		      old one and is regarded much more secure, but  is  not  interoperable  with
		      older  (MIT/SEAM)  servers.  The	new  protocol  is used by default, unless
		      explicitly specified using these options or through krb5.conf(4).  If  Ker-
		      beros  authorization  fails  when  using	the old "rcmd" protocol, there is
		      fallback to regular, non-kerberized rsh. This is not the case when the new,
		      more secure "rcmd" protocol is used.

       -x	      Cause the network session traffic to be encrypted. See DESCRIPTION.

       The type of remote shell (sh, rsh, or other) is determined by the user's entry in the file
       /etc/passwd on the remote system.

       The following operand is supported:

       command	  The command to be executed on the specified hostname.

       See largefile(5) for the description of the behavior of rsh and	remsh  when  encountering
       files greater than or equal to 2 Gbyte ( 2^31 bytes).

       The  rsh and remsh commands are IPv6-enabled. See ip6(7P). IPv6 is not currently supported
       with Kerberos V5 authentication.

       Hostnames are given in the hosts database, which can be contained in the /etc/hosts  file,
       the  Internet  domain  name  database, or both. Each host has one official name (the first
       name in the database entry) and optionally one or more nicknames.  Official  hostnames  or
       nicknames can be given as hostname.

       If  the	name of the file from which rsh is executed is anything other than rsh, rsh takes
       this name as its hostname argument. This allows you to create a symbolic link  to  rsh  in
       the  name of a host which, when executed, invokes a remote shell on that host. By creating
       a directory and populating it with symbolic links in the names  of  commonly  used  hosts,
       then  including the directory in your shell's search path, you can run rsh by typing host-
       name to your shell.

       If rsh is invoked with the basename remsh, rsh  checks  for  the  existence  of	the  file
       /usr/bin/remsh.	If  this  file	exists,  rsh  behaves as if remsh is an alias for rsh. If
       /usr/bin/remsh does not exist, rsh behaves as if remsh is a host name.

       For the kerberized rsh session, each user can have a private authorization list in a  file
       .k5login in their home directory. Each line in this file should contain a Kerberos princi-
       pal name of the form principal/instance@realm. If there is a ~/.k5login file, then  access
       is  granted  to	the account if and only if the originater user is authenticated to one of
       the principals named in the ~/.k5login file. Otherwise, the originating	user  is  granted
       access  to  the account if and only if the authenticated principal name of the user can be
       mapped to the local account name using the authenticated-principal-name -> local-user-name
       mapping	rules.	The .k5login file (for access control) comes into play only when Kerberos
       authentication is being done.

       For the non-secure rsh session, each remote machine can have a file named /etc/hosts.equiv
       containing a list of trusted hostnames with which it shares usernames. Users with the same
       username on both the local and remote machine can run rsh from the machines listed in  the
       remote  machine's  /etc/hosts.equiv  file.  Individual  users can set up a similar private
       equivalence list with the file .rhosts in their home directories. Each line in  this  file
       contains  two names: a hostname and a username separated by a space. The entry permits the
       user named username who is logged into hostname to use rsh to access the remote machine as
       the  remote  user. If the name of the local host is not found in the /etc/hosts.equiv file
       on the remote machine, and the local username and hostname are not  found  in  the  remote
       user's	.rhosts   file,   then	the  access  is  denied.  The  hostnames  listed  in  the
       /etc/hosts.equiv and .rhosts files must be the official	hostnames  listed  in  the  hosts
       database; nicknames can not be used in either of these files.

       You  cannot log in using rsh as a trusted user from a trusted hostname if the trusted user
       account is locked.

       rsh does not prompt for a password if access is denied on the remote  machine  unless  the
       command argument is omitted.

       Example 1 Using rsh to Append Files

       The  following  command appends the remote file lizard.file from the machine called lizard
       to the file called example.file on the machine called example:

	 example% rsh lizard cat lizard.file >> example.file

       The following command appends the file lizard.file on the machine  called  lizard  to  the
       file lizard.file2 which also resides on the machine called lizard:

	 example% rsh lizard cat lizard.file ">>" lizard.file2

       The following exit values are returned:

       0    Successful completion.

       1    An error occurred.

       /etc/hosts	      Internet host table

       /etc/hosts.equiv       Trusted remote hosts and users

       /etc/passwd	      System password file

       $HOME/.k5login	      File containing Kerberos principals that are allowed access

       /etc/krb5/krb5.conf    Kerberos configuration file

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

       |      ATTRIBUTE TYPE	     |	    ATTRIBUTE VALUE	   |
       |Availability		     |SUNWrcmdc 		   |
       |CSI			     |Enabled			   |

       on(1),	rlogin(1),  ssh(1),  telnet(1),  vi(1),  in.rshd(1M),  hosts(4),  hosts.equiv(4),
       krb5.conf(4), attributes(5), krb5_auth_rules(5), largefile(5), ip6(7P)

       When a system is listed in hosts.equiv, its security must be as good  as  local	security.
       One  insecure  system listed in hosts.equiv can compromise the security of the entire sys-

       You cannot run an interactive command (such as vi(1)). Use rlogin if you wish to do this.

       Stop signals stop the local rsh process only. This is arguably wrong, but  currently  hard
       to fix for reasons too complicated to explain here.

       The current local environment is not passed to the remote shell.

       Sometimes the -n option is needed for reasons that are less than obvious. For example, the

	 example% rsh somehost dd if=/dev/nrmt0 bs=20b | tar xvpBf -

       puts your shell into a strange state. Evidently, the tar process terminates before the rsh
       process. The rsh command then tries to write into the ``broken pipe'' and, instead of ter-
       minating neatly, proceeds to compete with your shell for its standard input. Invoking  rsh
       with the -n option avoids such incidents.

       This  bug  occurs only when rsh is at the beginning of a pipeline and is not reading stan-
       dard input. Do not use the -n option if rsh actually needs to  read  standard  input.  For

	 example% tar cf - . | rsh sundial dd of=/dev/rmt0 obs=20b

       does  not produce the bug. If you were to use the -n option in a case like this, rsh would
       incorrectly read from /dev/null instead of from the pipe.

       For most purposes, ssh(1) is preferred over rsh.

SunOS 5.11				   23 Dec 2008					   rsh(1)
Unix & Linux Commands & Man Pages : ©2000 - 2018 Unix and Linux Forums

All times are GMT -4. The time now is 04:34 PM.