rsh
========================================================================
                         **** CAUTION ****
For security reasons, the use of the r-command is completely discouraged.
Instead, you should seriously consider use of the ssh related tools.
This package is mainly intended for compatibility.
                         *****************

The rsh package contains a set of programs which allow users to run
commmands on remote machines, login to other machines and copy files
between machines (rsh, rlogin and rcp). All three of these commands use
rhosts style authentication.  This package contains the clients needed
for all of these services.  It also contains the rexec client, which is
similar to rsh but uses netrc style authentication. This package contains
the clients needed for all of these services. The rsh package should be
installed to enable remote access to other machines."

Note that these clients are security nightmares, dating from a time when
the internet was a more innocent place. Not only do rlogin, rsh, and rcp
transmit your username and password unencrypted, but rexec uses .netrc-
style authentication, where your username and password are stored,
unencrypted, in a file in your home directory on every client machine,
and transmits it unencrypted to the server.

It is NOT recommended that you install or use ANY of these utilities
unless you have a VERY good reason.  All of the r* clients may be
replaced by the cryptographically secure ssh client from the cygwin
'openssh' package.

So why is this package present?  Because as insecure and flawed as they
are, the r* tools, servers, and protocols are still in wide use, and
their conspicuous absence from the cygwin distribution would be viewed
as a flaw, not a feature.
========================================================================

Build requirements
  cygwin-1.7.24-1
  cygport-0.13.0-1
  crypt
  gcc
  binutils
  perl
  texinfo

Canonical homepage:
  n/a

Canonical download:
  http://ftp.linux.org.uk/pub/linux/Networking/netkit/

License:
  BSD

Language:
  C

========================================================================

Port Notes:

This port supports only cygwin-1.7 or newer, and only Windows NT 4.0
and above (as that version of cygwin only supoorts these newer OSs).

In some cases, client applications may experience long delays during
authentication.  There are two possible explanations:

  1) Poor DNS configuration; make sure the client can do both forward
     and reverse DNS lookups of the server, and that the server can
     do both forward and reverse DNS lookups of the client.

  2) In some cases, the *client* machine must be running an identd
     server, so that the *server* daemon can do an auth callback.
     Cygwin does not yet have a ported identd daemon, but the following
        http://rndware.info/products/windows-ident-server.html
     works pretty well. It's a free-as-in-beer, but closed-source,
     identd service for Win32.  You'll need to open a hole in your
     firewall at port 113, for any identd service you install. On
     Windows Vista, enter the following command from an Administrator
     cmd prompt (or use the Control Panel GUI):
        netsh advfirewall firewall add rule name="auth" action=allow protocol=TCP dir=in localport=113

Configuration
------------------------------------------------------------------------
There are four separate clients provided in this package, which
provide the following services:

   service name   server     client(s)    port
   -------------  ---------  ---------    -------
   shell          rshd       rsh, rcp     514/tcp
   login          rlogind    rlogin       513/tcp
   exec           rexecd     rexec        512/tcp

Some of the r* tools use "rhosts" authentication; others use "netrc"
authentication.  For rhosts, you need a ~/.rhosts file on the server
machine, which specifies which client machines a particular user is
allowed to connect from.  For netrc, you need a ~/.netrc file on the
client machine, which specifies the logon credentials to be used with
each server you may want to contact.  Netrc is a particularly lovely
security horror, as it exposes, in plain text, your passwords for
multiple remote computers -- and users tend to copy the file around
to many different client computers with varying trustworthiness.

Needed for passwordless rsh, rlogin, rcp:

        ~/.rhosts contents
	(on remote server)
        ------------------
        localhost
        mycomputer
        myfileserver
        some.remote.host.net


Used for passwordless rexec:

        ~/.netrc contents
	(on local client)
        -----------------
        machine mycomputer
        login username1
        password 12345
        machine somehost.out-there.on-the.net
        login username2
        password on-my-luggage

See the more detailed notes concerning each individual service below.


rlogin
------------------------------------------------------------------------
The rlogin protocol uses ~/.rhosts for passwordless logons.

rlogin issues:
+++++++++++++++
1) On a multi-homed machine, you sometimes can't rlogin to localhost via
   its short hostname (but 'localhost' and the fully-qualified name both
   work). See /usr/share/doc/Cygwin/tcp_wrappers.README for more info.

rlogin notes:
+++++++++++++++
The client machine MAY need to also have an identd server running, and
accessible to the server machine (that is, a hole in the client's own
firewall, allowing incoming (rlogin-server --> rlogin-client) connecctions.


rsh, rcp
------------------------------------------------------------------------
The rsh protocol uses ~/.rhosts for passwordless logons.

rsh issues:
+++++++++++++++
1) On a multi-homed machine, you sometimes can't rsh to localhost via
   its short hostname (but 'localhost' and the fully-qualified name both
   work). See /usr/share/doc/Cygwin/tcp_wrappers.README for more info.

rsh notes:
+++++++++++++++
The client machine MAY need to also have an identd server running, and
accessible to the server machine (that is, a hole in the client's own
firewall, allowing incoming (rlogin-server --> rlogin-client) connecctions.

Finally, on the *client* machine, you may need to allow a 'program
exception' in your firewall for the rsh client. The rsh protocol allows the
client to specify an additional port (other than 514) that the server will
contact, to send stderr information.  This port is random, but you need to
allow incoming connections on your *client* machine at that port. Windows
has no 'stateful' filters for the rsh protocol, so you need to allow the rsh
program to 'answer' on any port: thus, a 'program exception'.

   netsh advfirewall firewall add rule name="Cygwin rsh.exe client" action=allow dir=in program="`cygpath -m /usr/bin/rsh.exe`" enable=yes

rexec
------------------------------------------------------------------------
The rexec protocol uses ~/.netrc for passwordless logons.

rexec issues:
+++++++++++++++
1) On a multi-homed machine, you sometimes can't rexec to localhost via
   its short hostname (but 'localhost' and the fully-qualified name both
   work). See /usr/share/doc/Cygwin/tcp_wrappers.README for more info.

rexec notes:
+++++++++++++++
For passwordless rexec, you need an ~/.netrc file on the client machine,
with at most 644 (but preferably 600) permissions.  That is,
    '-rw-r--r-- .netrc'

In addition to ~/.netrc, rexec also allows login credentials to be
specified via environment variables (on the client) or on the command
line:

    $ REXEC_USER=myuser
    $ REXEC_PASS=12345
    $ rexec some-host ls -l

or

    $ rexec -l myuser -p 12345 some-host ls -l

In either case, you password is will be visible in plain text in your
~/.history or ~/.bash_history file.  At least in the second case,
the rexec client will blank out the password text from
/proc/<pid>/cmdline.

Are you SURE you can't use sshd?

The client machine MAY need to also have an identd server running, and
accessible to the server machine (that is, a hole in the client's own
firewall, allowing incoming (rexec-server --> rexec-client) connecctions.

Finally, on the *client* machine, you may need to allow a 'program
exception' in your firewall for the rexec client. The rexec protocol allows
the client to specify an additional port (other than 512) that the server
will contact, to send stderr information.  This port is random, but you need
to allow incoming connections on your *client* machine at that port. Windows
has no 'stateful' filters for the rexec protocol, so you need to allow the
rexec program to 'answer' on any port: thus, a 'program exception'.

   netsh advfirewall firewall add rule name="Cygwin rexec.exe client" action=allow dir=in program= ="`cygpath -m /usr/bin/rexec.exe`" enable=yes

Some rexec clients, including the one supplied here, have an option ('-a')
that combines both stdout and stderr channels on the original port 512; with
this option you don't need to open a hole in your client's firewall, but
output can be jumbled.

========================================================================
Change History

---------- rsh-0.17-3 -- 2021 Feb 6 -----------
* Introduced some new patches from fedora
* Added IPv6 support to rexec and rcp

---------- rsh-0.17-2 -- 2013 Aug 18 -----------
* Rely on cygport to autogenerate setup.hints
* Added debuginfo package
* First cygwin64 release

---------- rsh-0.17-1 -- 27 Mar 2010 -----------
* Initial release (replaces portions of inetutils)
  Based on the fedora 13 release of (netkit) rsh.
* Nominally supports IPv6 but (a) inetd does not, and (b) IPv6 support
  is untested, even when used in conjunction with the new cygwin release
  of xinetd, which also (nominally) supports IPv6. However, the r*
  tools do work in a IPv6-aware IPv4 environment (which is actually a
  common scenario with Windows Vista and above).

========================================================================
Cygwin port maintained by:  Charles Wilson  <cygwin@cygwin.com>

