NAME¶
rsh —
remote shell
SYNOPSIS¶
rsh |
[-45FGKdefnuxz]
[-U string]
[-p port]
[-l
username]
[-P N|O]
host [command] |
DESCRIPTION¶
rsh authenticates to the
rshd(8) daemon on
the remote
host, and then executes the specified
command.
rsh copies its standard input to the remote command, and the
standard output and error of the remote command to its own.
Valid options are:
- -4,
--krb4
- The -4 option requests Kerberos 4
authentication. Normally all supported authentication mechanisms will be
tried, but in some cases more explicit control is desired.
- -5,
--krb5
- The -5 option requests Kerberos 5
authentication. This is analogous to the -4 option.
- -K,
--broken
- The -K option turns off all Kerberos
authentication. The security in this mode relies on reserved ports. The
long name is an indication of how good this is.
- -n,
--no-input
- The -n option directs the input from the
/dev/null device (see the
BUGS section of this manual page).
- -d
- Enable setsockopt(2) socket
debugging.
- -e,
--no-stderr
- Don't use a separate socket for the stderr stream. This can
be necessary if rsh-ing through a NAT bridge.
- -x,
--encrypt
- The -x option enables encryption for all
data exchange. This is only valid for Kerberos authenticated connections
(see the BUGS section for
limitations).
- -z
- The opposite of -x. This is the default,
and is mainly useful if encryption has been enabled by default, for
instance in the
appdefaults
section of
/etc/krb5.conf when using Kerberos 5.
- -f,
--forward
- Forward Kerberos 5 credentials to the remote host. Also
settable via
appdefaults
(see
krb5.conf).
- -F,
--forwardable
- Make the forwarded credentials re-forwardable. Also
settable via
appdefaults
(see
krb5.conf).
- -l
string,
--user=string
- By default the remote username is the same as the local.
The -l option or the username@host
format allow the remote name to be specified.
- -n,
--no-input
- Direct input from /dev/null (see the
BUGS section).
- -p
number-or-service,
--port=number-or-service
- Connect to this port instead of the default (which is 514
when using old port based authentication, 544 for Kerberos 5 and
non-encrypted Kerberos 4, and 545 for encrytpted Kerberos 4; subject of
course to the contents of /etc/services).
- -P
N|O|1|2,
--protocol=N|O|1|2
- Specifies the protocol version to use with Kerberos 5.
N and 2 select protocol
version 2, while O and 1
select version 1. Version 2 is believed to be more secure, and is the
default. Unless asked for a specific version, rsh will
try both. This behaviour may change in the future.
- -u,
--unique
- Make sure the remote credentials cache is unique, that is,
don't reuse any existing cache. Mutually exclusive to
-U.
- -U
string,
--tkfile=string
- Name of the remote credentials cache. Mutually exclusive to
-u.
- -x,
--encrypt
- The -x option enables encryption for all
data exchange. This is only valid for Kerberos authenticated connections
(see the BUGS section for
limitations).
- -z
- The opposite of -x. This is the default,
but encryption can be enabled when using Kerberos 5, by setting the
libdefaults/encrypt
option in
krb5.conf(5).
EXAMPLES¶
Care should be taken when issuing commands containing shell meta characters.
Without quoting, these will be expanded on the local machine.
The following command:
rsh otherhost cat remotefile >
localfile
will write the contents of the remote
remotefile to the local
localfile, but:
rsh otherhost 'cat remotefile >
remotefile2'
will write it to the remote
remotefile2.
FILES¶
- /etc/hosts
-
SEE ALSO¶
ktelnet(1),
krb_realmofhost(3),
krb_sendauth(3),
hosts.equiv(5),
krb5.conf(5),
rhosts(5),
kerberos(8) rshd(8)
HISTORY¶
The
rsh command appeared in
4.2BSD.
AUTHORS¶
This implementation of
rsh was written as part of the Heimdal
Kerberos 5 implementation.
BUGS¶
Some shells (notably
csh(1)) will cause
rsh
to block if run in the background, unless the standard input is directed away
from the terminal. This is what the
-n option is for.
The
-x options enables encryption for the session, but for
both Kerberos 4 and 5 the actual command is sent unencrypted, so you should
not send any secret information in the command line (which is probably a bad
idea anyway, since the command line can usually be read with tools like
ps(1)). Forthermore in Kerberos 4 the command is not even
integrity protected, so anyone with the right tools can modify the
command.