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//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