Test configuration: cygwin-1.7.2-2 Windows Vista (I figure if it works there, it'll work on XP and below; Windows 7 or Server2008? Well, we'll see) xinetd-2.3.14-1 inetutils-1.7-1 rsh-0.17-1 rsh-server-0.17-1 tcp_wrappers-7.6-21 tftpd, tftp not tested talk, talkd not tested uucpd not tested "ok" means with all the necessary setup, I was able to make a passwordless connection between the two machines. That is, proper firewall configuration, a good ~/.rhosts and ~/.netrc file, etc. (And, of course, actually editing the appropriate /etc/xinetd.d/* or /etc/inetd.conf file to enable the service in question). CLIENTS ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ to remote machine ======================================================== othermachine othermachine.mydomain rlogin ok (1) ok (1) rsh ok (1) ok (1) rsh (ls -l) ok (1) ok (1) rcp remote:file . ok (1) ok (1) rcp file remote: ok (1) ok (1) rexec (ls -l) ok (1) ok (2,1) rexec -a (ls -l) ok (1) ok (2,1) telnet (inetutils, mintty) ok (3) ok (3) telnet (inetutils, cmd) ok (3) ok (3) ftp active get ok (4,1) ok (4,1) ftp active put ok (4,1) ok (4,1) ftp passive get ok (4,1) ok (4,1) ftp passive put ok (4,1) ok (4,1) [1] very slow (connecting to my linux server) unless vista machine was running an identd server and had an opening it its firewall for the auth (ident) port (113). (For ftp, it's only a few seconds; but for the r* tools it's 30 seconds; this has to do with the characteristics of the remote server; linux:netkit-rsh-server vs linux:proftpd). [2] For passwordless rexec, the .netrc file must have separate entries for both name variations: 'othermachine' not 'othermachine.mydomain'). Oddly, the ftp client, which also uses .netrc for passwordless auth- entication, requires only 'othermachine'. [3] a note on server config: my linux telnet server was kerboros-enabled, and was set up to reject non-krb connections. I had to explicitly comment out the following from linux:/etc/xinetd.d/telnet # server_args = -a valid -e or it would reject all non-kerboros connections. THere is, however, no identd-related delay. [4] uses .netrc authentication. In this case, even though .netrc still only lists 'othermachine', both othermachine and othermachine.mydomain work -- probably because the ftp client has smarter string matching than rexec (actually, cygwin's rcmd() implementation) -- ftp.exe implements the .netrc parsing itself, unlike rexec.exe. SERVERS ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ (a) == using tcp_client to test (b) == using telnet to test SUPERSERVER XINETD -- builtin services -- from local machine ========================================================= 9098 chargen daytime discard echo time tcp localhost (a) ok ok ok ok ok ok tcp mymachine (a) ok ok ok ok ok ok tcp mymachine.mydomain (a) ok ok ok ok ok ok tcp localhost (b) ok ok ok ok ok ok tcp mymachine (b) na (1) ok ok ok ok ok tcp mymachine.mydomain (b) na (1) ok ok ok ok ok udp localhost na ok ok ok ok ok udp mymachine na ok ok ok ok ok udp mymachine.mydomain na ok ok ok ok ok [1] This service is explicitly enabled only for tcp 127.0.0.1/localhost, so it is not surprising that it is inaccessible when contacted via a different interface or protocol. SUPERSERVER XINETD -- builtin services -- from remote machine ========================================================== 9098 chargen daytime discard echo time tcp mymachine (a) na ok ok ok ok ok tcp mymachine.mydomain (a) na ok ok ok ok ok tcp mymachine (b) na ok ok ok ok ok tcp mymachine.mydomain (b) na ok ok ok ok ok udp mymachine na ok ok ok ok ok udp mymachine.mydomain na ok ok ok ok ok SUPERSERVER XINETD -- other services -- from remote machine (IPv6) ================================================================== mymachine mymachine.mydomain IPv6 or IPv4: rlogin ok ok rsh ok ok rsh (ls -l) ok ok rcp remote:file . ok ok rcp file remote: ok ok rexec (ls -l) X (1) X (1) rexec -a (ls -l) ok ok IPv4 only: telnet ok ok ftp ls ok (2) ok (2) ftp active get ok (2) ok (2) ftp active put ok (2) ok (2) ftp passive get ok (2) ok (2) ftp passive put ok (2) ok (2) [1] no error message, but client hangs forever. This is because rexecd can't set up the stderr connection back to the client, because it is blocked by the firewall on the client machine (turning off the firewall entirely allows the connection to succeed). So, the server gives up after 20 seconds, but the (linux) client never does. [2] Client needs an identd server running, or there is a very long delay. SUPERSERVER XINETD -- other services -- from local machine ======================================================= localhost mymachine mymachine.mydomain IPv6 or IPv4: rlogin ok ok (1) ok rsh ok ok (1) ok rsh (ls -l) ok ok (1) ok rcp remote:file . ok ok (1) ok rcp file remote: ok ok (1) ok rexec (ls -l) ok (2,3) ok (1,2,3) ok (2,3) rexec -a (ls -l) ok (2) ok (1,2) ok (2) IPv4 only: telnet (putty) ok X (4) ok telnet (inetutils, mintty) ok ok ok telnet (inetutils, cmd) ok (5) ok (5) ok (5) ftp ls ok ok ok ftp active get ok ok ok ftp active put ok ok ok ftp passive get ok ok ok ftp passive put ok ok ok [1] Only if the the local machine is not multi-homed (that is, it is associated with only one network; or, ALL of the networks with which it IS associated have matching rules in /etc/hosts.allow) [2] For passwordless rexec to work, you must have a separate entry in .netrc for each variations on the name that you wish to use in the rexec command line: 'localhost', 'mymachine', and 'mymachine.mydomain'. Oddly, the ftp client, which also uses .netrc for passwordless authentication, needs only one entry: 'mymachine'. [3] You need to have a 'program exception' in your firewall for the /usr/bin/rexec.exe client, or rexec won't work at all without -a. This is because the protocol expects the server to make a connection BACK to the client, for stderr. [4] The telnetd server logs don't seem to show any problem; it seems this issue is on the 'putty' side. [5] Keyboard input is odd; extra spaces between each letter and backspace doesn't move the cursor (but it does 'erase' the characters in the input buffer). This is a longstanding issue with cygwin telnet, but it affects only loopback connections, and only when in cmd.exe (or console2). The telnet server works fine when non-cygwin clients connect; or when the cygwin client connects from a non-cmd console. The telnet client works fine connecting to non-cygwin servers, or when connecting to the cygwin server from a non-cmd console. I'm delaying this investigation. SUPERSERVER INETD -- builtin services -- from local machine ======================================================== chargen daytime discard echo time tcp localhost (a) ok ok ok ok ok tcp mymachine (a) ok ok ok ok ok tcp mymachine.mydomain (a) ok ok ok ok ok tcp localhost (b) ok ok ok ok ok tcp mymachine (b) ok ok ok ok ok tcp mymachine.mydomain (b) ok ok ok ok ok udp localhost ok ok ok ok ok udp mymachine ok ok ok ok ok udp mymachine.mydomain ok ok ok ok ok SUPERSERVER INETD -- builtin services -- from remote machine ========================================================= chargen daytime discard echo time tcp mymachine (a) ok ok ok ok ok tcp mymachine.mydomain (a) ok ok ok ok ok tcp mymachine (b) ok ok ok ok ok tcp mymachine.mydomain (b) ok ok ok ok ok udp mymachine ok ok ok ok ok udp mymachine.mydomain ok ok ok ok ok SUPERSERVER INETD -- other services -- from remote machine (IPv4) ================================================================== mymachine mymachine.mydomain IPv4 only: rlogin ok ok rsh ok ok rsh (ls -l) ok ok rcp remote:file . ok ok rcp file remote: ok ok rexec (ls -l) X (1) X (1) rexec -a (ls -l) ok ok telnet ok ok ftp ls ok (2) ok (2) ftp active get ok (2) ok (2) ftp active put ok (2) ok (2) ftp passive get ok (2) ok (2) ftp passive put ok (2) ok (2) [1] no error message, but client hangs forever. This is because rexecd can't set up the stderr connection back to the client, because it is blocked by the firewall on the client machine (turning off the firewall entirely allows the connection to succeed). So, the server gives up after 20 seconds, but the (linux) client never does. [2] Client needs an identd server running, or there is a very long delay. SUPERSERVER INETD -- other services -- from local machine ======================================================= localhost mymachine mymachine.mydomain IPv4 only: rlogin ok ok (1) ok rsh ok ok (1) ok rsh (ls -l) ok ok (1) ok rcp remote:file . ok ok (1) ok rcp file remote: ok ok (1) ok rexec (ls -l) ok (2,3) ok (1,2,3) ok (2,3) rexec -a (ls -l) ok (2) ok (1,2) ok (2) telnet (putty) ok X (4) ok telnet (inetutils, mintty) ok ok ok telnet (inetutils, cmd) ok (5) ok (5) ok (5) ftp ls ok ok ok ftp active get ok ok ok ftp active put ok ok ok ftp passive get ok ok ok ftp passive put ok ok ok [1] Only if the the local machine is not multi-homed (that is, it is associated with only one network; or, ALL of the networks with which it IS associated have matching rules in /etc/hosts.allow) [2] For passwordless rexec to work, you must have a separate entry in .netrc for each variations on the name that you wish to use in the rexec command line: 'localhost', 'mymachine', and 'mymachine.mydomain'. Oddly, the ftp client, which also uses .netrc for passwordless authentication, needs only one entry: 'mymachine'. [3] You need to have a 'program exception' in your firewall for the /usr/bin/rexec.exe client, or rexec won't work at all without -a. This is because the protocol expects the server to make a connection BACK to the client, for stderr. [4] The telnetd server logs don't seem to show any problem; it seems this issue is on the 'putty' side. [5] Keyboard input is odd; extra spaces between each letter and backspace doesn't move the cursor (but it does 'erase' the characters in the input buffer). This is a longstanding issue with cygwin telnet, but it affects only loopback connections, and only when in cmd.exe (or console2). The telnet server works fine when non-cygwin clients connect; or when the cygwin client connects from a non-cmd console. The telnet client works fine connecting to non-cygwin servers, or when connecting to the cygwin server from a non-cmd console. I'm delaying this investigation.