Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
rsh(1)				 User Commands				rsh(1)

       rsh, remsh, remote_shell	- remote shell

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

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

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

       remsh hostname [-n] [-a]	[-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.	Inter-
       rupt, 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  pos-
       sible.  The  rsh	 session  can be kerberized using any of the following
       Kerberos	specific options: -a, -PN or -PO, -x, -f or -F,	and -k	realm.
       Some of these options (-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  ac-
       count  is controlled by rules in	krb5_auth_rules(5). If this authoriza-
       tion 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 ma-
       chine. 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 traffic is encrypted. See -x.

       The following options are supported:

       -a	       Explicitly enable Kerberos  authentication  and	trusts
		       the .k5login file for access-control. If	the authoriza-
		       tion 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 op-
		       tion is mutually	exclusive with the -F option.

       -F	       Forward	a  forwardable	copy  of the local credentials
		       (Kerberos Ticket	Granting Ticket) to the	remote system.
		       The  -F option provides a superset of the functionality
		       offered by the -f option. For example, with the -f  op-
		       tion,  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  sys-
		       tem. This option	is mutually exclusive with the -f  op-

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

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

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

       -PO	       Explicitly  request  new	 (-PN) or old (-PO) version of
       -PN	       the Kerberos "rcmd" 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 op-
		       tions  or  through krb5.conf(4).	If Kerberos authoriza-
		       tion 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

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

       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

       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 exe-
       cuted, 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 hostname 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  be-
       haves as	if remsh is a host name.

       For the kerberized rsh session, each user can have a private authoriza-
       tion list in a file .k5login in their home directory. Each line in this
       file should contain a Kerberos principal	name of	the form principal/in-
       stance@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	origi-
       nating user is granted access to	the account if and only	if the authen-
       ticated 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 lo-
       cal and remote  machine can run rsh from	the machines listed in the re-
       mote  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 user-
       name  who  is  logged into hostname to use rsh to access	the remote ma-
       chine 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	 data-
       base; 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 ma-
       chine 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  ma-
       chine 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),   telnet(1),	   vi(1),    in.rshd(1M),    hosts(4),
       hosts.equiv(4),	    ipnodes(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 compro-
       mise the	security of the	entire system.

       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	 obvi-
       ous. For	example, the command:

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

       puts your shell into a strange state. Evidently,	the tar	process	termi-
       nates before the	rsh process. The rsh command then tries	to write  into
       the  ``broken  pipe''  and,  instead of terminating 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 standard input. Do not use the -n option  if	 rsh  actually
       needs to	read standard input. For example:

       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.

SunOS 5.10			  26 May 2004				rsh(1)


Want to link to this manual page? Use this URL:

home | help