rsh-server
========================================================================
                         **** 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-server 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 servers needed
for all of these services. It also contains a server for rexec, an
alternate method of executing remote commands. All of these servers must
be run by a 'super-server' such as inetd or xinetd, and as such are
configured by /etc/inetd.conf or /etc/xinetd.d/* -- the servers can not
be launched standalone nor via cygrunsrv.

Configuration scripts for these servers are installed into
/etc/xinetd.d, but are disabled by default.

Note that these servers 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 enable or use ANY of these utilities
unless you have a VERY good reason. Even then, you should employ
firewall protection and tcp_wrappers. All of the r* servers may be
replaced by the cryptographically secure sshd server 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.

Security announcement
========================================================================

In addition to the routine insecurity endemic to the r* protocols,
please be aware that if you have created your /etc/passwd via 
'mkpasswd -l' then you may have a security hole.

If your PC has `guest' login enabled in order to allow shares to certain
directories on your Windows box, your passwd file contains an entry for
Guest that will allow anyone to ftp, telnet, rsh, rlogin, etc. to your
machine simply by using user guest and pressing enter for the password.
One solution is to eliminate the guest account via user manager. The
other is to delete the guest entry in /etc/passwd.  However, this option
is unattractive if you want to use the `guest' user for anonymous ftp.
In that case, you should AT LEAST change the user's shell entry in
/etc/passwd to something like /bin/false or /bin/date to avoid
interactive login without password for 'guest'.

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

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

By default, all services are disabled. You must manually edit
/etc/inetd.conf or /etc/xinetd.d/* (depending on which super-server
you use) to activate any services.

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="ident" action=allow protocol=TCP dir=in localport=113

Configuration
------------------------------------------------------------------------
There are three separate servers 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

Each server runs with the same privileges that the superserver
(inetd, xinetd).  This is probably the Windows analogue of the 
unix 'root' account (that is, SYSTEM/LocalSystem on WinNT, WinXP;
or a special privileged user 'cyg_server' on windows 2003, Vista,
and above). These servers, themselves, provide no access restrictions;
you must configure tcp_wrappers and your windows firewall appropriately.

But...wouldn't you rather use ssh?

If you are using inetd as the superserver, then you should install the
tcp_wrappers package, and edit /etc/inetd.conf to enable the desired
service through tcpd:

  BAD:    rlogin  stream  tcp     nowait  root    /usr/sbin/rlogind rlogind
  BETTER: rlogin  stream  tcp     nowait  root    /usr/sbin/tcpd rlogind
  BEST:   #rlogin  don't care, use sshd instead

And assert appropriate access restrictions in /etc/hosts.allow and 
/etc/hosts.deny (see `man -s 5 hosts_access').


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.


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

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

rlogind conf:
+++++++++++++
If you are using inetd, then you should install the tcp_wrappers package,
and edit /etc/inetd.conf as follows:

    login   stream  tcp     nowait  root    /usr/sbin/tcpd rlogind

Then, add something like the following to /etc/hosts.allow:

    rlogind: 192.168.1.0/255.255.255.0

If you are using xinetd, then you should edit the /etc/xinetd.d/rlogin
file, and change the line that reads:

        disable                 = yes
to
        disable                 = no

xinetd uses tcp_wrappers automatically.


On Windows XP and above, you may also need to allow port 513/TCP through
the Windows Firewall (or whatever firewall software you are using. You ARE
using firewall software, right?)
  
In Windows Vista, this can be done by launching a cmd shell 'as administrator',
and issuing the following command.  You may find the second command necessary
as well:

    netsh advfirewall firewall add rule name="Cygwin service login" action=allow protocol=TCP dir=in localport=513 enable=yes
    netsh advfirewall firewall add rule name="Cygwin rlogind.exe" action=allow dir=in program="`cygpath -m /usr/sbin/rlogind.exe`" enable=yes

For passwordless rlogin, you need an ~/.rhosts file on the host machine,
with at most 644 (but preferably 600) permissions.  That is,

    '-rw-r--r-- .rhosts'

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.

rshd
------------------------------------------------------------------------
The rsh protocol uses ~/.rhosts for passwordless logons. Note that the
rshd server provides the facilities for both the rsh and rcp clients.

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

rshd conf:
+++++++++++++
If you are using inetd, then you should install the tcp_wrappers package,
and edit /etc/inetd.conf as follows:

    shell   stream  tcp     nowait  root    /usr/sbin/tcpd rshd -L
  
Then, add something like the following to /etc/hosts.allow:

    rshd: 192.168.1.0/255.255.255.0

If you are using xinetd, then you should edit the /etc/xinetd.d/rsh
file, and change the line that reads:

        disable                 = yes
to
        disable                 = no

xinetd uses tcp_wrappers automatically.


On Windows XP and above, you may also need to allow port 514/TCP through
the Windows Firewall (or whatever firewall software you are using. You ARE
using firewall software, right?)
  
In Windows Vista, this can be done by launching a cmd shell 'as administrator',
and issuing the following command:

    netsh advfirewall firewall add rule name="Cygwin service shell" action=allow protocol=TCP dir=in localport=514 enable=yes
    netsh advfirewall firewall add rule name="Cygwin rshd.exe" action=allow dir=in program="`cygpath -m /usr/sbin/rshd.exe`" enable=yes

For passwordless rsh, you need an ~/.rhosts file on the host machine,
with at most 644 (but preferably 600) permissions.  That is,

    '-rw-r--r-- .rhosts'

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 (rsh-server --> rsh-client) connecctions.

When the rsh client is invoked without an explicit command, it delegates
to rlogin. For this reason, if you enable the rsh server you will probably
also need to enable and configure the rlogin server as well.

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'. e.g.

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

NOTE: To test the cygwin server, I needed to do something similar for the
linux rsh client:
	ACCEPT  net     fw      tcp     514		-
	ACCEPT  net     fw      tcp:syn 512:1023	1:1023
The first line is for the linux rshd server; the second allows the linux
client to accept the stderr port (since linux doesn't have a stateful
filter for rsh either, and it doesn't have "program exceptions"). The
stderr connection will originate from the rshd server on a privileged
port, and will contact an upper-half privileged port on the client machine.
That is, rshd(1-1023)-->rsh(512-1023).

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

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

2) It's almost impossible to get an rexec client on linux to work
   without using the "-a" switch. Unlike with rshd, there is no "rule"
   governing the ports that will be used to create the stderr callback
   connection; you pretty much have to turn off your client machine's
   firewall in toto.

   Fortunately, the '-a' option allows to avoid the issue. Also, the
   windows firewall has "program exceptions", so you can usually get
   the *cygwin* rexec client to work without '-a'.


rexecd conf:
+++++++++++++
If you are using inetd, then you should install the tcp_wrappers package,
and edit /etc/inetd.conf as follows:

    exec    stream  tcp     nowait  root    /usr/sbin/tcpd rexecd
  
Then, add something like the following to /etc/hosts.allow:

    rexecd: 192.168.1.0/255.255.255.0

If you are using xinetd, then you should edit the /etc/xinetd.d/rexec
file, and change the line that reads:

        disable                 = yes
to
        disable                 = no

xinetd uses tcp_wrappers automatically.


On Windows XP and above, you may also need to allow port 512/TCP through
the Windows Firewall (or whatever firewall software you are using. You ARE
using firewall software, right?)
  
In Windows Vista, this can be done by launching a cmd shell 'as administrator',
and issuing the following command. You may also find the second command
necessary.

    netsh advfirewall firewall add rule name="Cygwin service exec" action=allow protocol=TCP dir=in localport=512 enable=yes
    netsh advfirewall firewall add rule name="Cygwin rexecd.exe" action=allow dir=in program="`cygpath -m /usr/sbin/rexecd.exe`" enable=yes

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 by the companion 'rsh'
cygwin package, 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 -- see rsh.README

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

