RSH(1) User Commands RSH(1)
NAME
rsh, remsh, remote_shell - remote shell
SYNOPSIS
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]
commandDESCRIPTION
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 kerberized 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
specified in the
[appdefaults] section of
krb5.conf(5). 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(7). 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(5). 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 traffic is encrypted. See
-x.
OPTIONS
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(8) 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 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 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(5).
-K This option explicitly disables Kerberos authentication.
It can be used to override the
autologin variable in
krb5.conf(5).
-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 username.
-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 -PN Explicitly request new (
-PN) or old (
-PO) version of the
Kerberos "
rcmd" protocol. The new protocol avoids many
security problems prevalent 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(5). If Kerberos 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.
OPERANDS
The following operand is supported:
command The command to be executed on the specified
hostname.
USAGE
See
largefile(7) 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(4P).
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
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 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 principal 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 originating 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.
EXAMPLES
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.file2EXIT STATUS
The following exit values are returned:
0 Successful completion.
1 An error occurred.
FILES
/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
ATTRIBUTES
See
attributes(7) for descriptions of the following attributes:
+---------------+-----------------+
|ATTRIBUTE TYPE | ATTRIBUTE VALUE |
+---------------+-----------------+
|CSI | Enabled |
+---------------+-----------------+
SEE ALSO
rlogin(1),
ssh(1),
telnet(1),
vi(1),
ip6(4P),
hosts(5),
hosts.equiv(5),
krb5.conf(5),
attributes(7),
krb5_auth_rules(7),
largefile(7),
in.rshd(8)NOTES
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 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 obvious.
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
terminates 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.
For most purposes,
ssh(1) is preferred over
rsh.
September 12, 2020
RSH(1)