Tribblix: manual page: remote

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] command

DESCRIPTION

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

EXIT 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 |
+---------------+-----------------+

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)