Mail Archives: cygwin/2010/03/28/14:20:30
--------------050004050102040804010805
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
After much pain and suffering, I've managed to restore what I consider
to be full functionality for the inetutils servers (rsh, rlogin, rcp,
telnet, ftp, ...). However, there's been some restructuring (and there
will be more in the future, but...not for a while.
Look for the following packages to be announced soon.
xinetd-2.3.14-1
inetutils-1.7-1
rsh-0.17-1
rsh-server-0.17-1
tcp_wrappers-7.6-21
libwrap0-7.6-21
libwrap-devel-7.6-21
All have been compiled under cygwin-1.7.2-2 with gcc4. (The previous
inetutils package, 1.5-6, was compiled only for cygwin-1.5 using gcc3).
TCP_WRAPPERS
============
I've made a few changes to tcp_wrappers and many of the servers so that
'localhost' is treated specially -- that is, it will match whatever
/etc/hosts.allow says about localhost -- in all of its various
incarnations ("localhost", 127.0.0.1, ::1, ::ffff:127.0.0.1, AND when
using the actual name or public IP address of the machine in question).
That is, if mymachine (with IP 192.168.51.27) is running the cygwin
telnet server, and I'm logged in to the mymachine console (that is, a
GUI login, Start Menu and all), then all of the following "act like"
'telnet localhost':
telnet localhost
telnet mymachine
telnet mymachine.mydomain
telnet 127.0.0.1
telnet 192.168.51.27
(telnet client doesn't yet support IPv6 addrs on cmd line, so
that's untested)
I've expanded the cygwin README for tcp_wrappers to address some issues
that came up in testing with regards to multi-homed computers (those
with more than one ethernet adapter: wireless+wired, or 'virtual' ones
like VMware...)
tcp_wrappers supports IPv6 (actually, the cygwin-1.7 version has since
last March).
XINETD
============
I've adopted and updated the xinetd package, and incorporated patches
from both debian and fedora to enable IPv6 support and fix a few bugs.
It also needed assistance with respect to localhost. I've added a LOT of
documentation.
I've added two utility programs for simple testing of network servers:
/usr/lib/xinetd/tcp_client
/usr/lib/xinetd/udp_client
xinetd supports IPv6.
R* TOOLS (rsh, etc)
============
The r* client and server tools have been moved to a new package, based
on the fedora (netkit)-rsh upstream source. These nominally support IPv6
connections, although I only tested them in IPv4-wrapped-in-IPv6
configuration.
rsh-0.17-1
rsh-server-0.17-1
These servers also needed some assistance with regards to localhost.
Moved all r*-tool relevant documentation from inetutils' cygwin README here.
The r* tools (supposedly) support IPv6.
INETUTILS
============
4) The inetutils package has been updated to upstream release 1.7.
However, it has NOT been compiled to support IPv6. (A) The support for
IPv6 in the inetd superserver is still somewhat lacking, (B) I'd rather
put that effort into xinetd, and (C) it seems that many of the slave
servers (ftpd, tftpd) OTHER than inetd, have no IPv6 support at all.
So...use xinetd if you want IPv6. Actually, use xinetd, period. All the
cool linux distros do.
I've removed from inetd the support for running as a service on its own,
without the assistance of cygserver. You can still install it as a
service WITH cygserver; in fact, that's what iu-config has done for the
past 18 months or so. Furthermore, for the past 12 months, inetd has
only supported '--remove-as-service'; the '--install-as-service' option
was removed long ago. So...the only way this change would affect
anyone, is if they (a) installed inetd as a standalone service two years
ago, (b) ignored all warnings and pleadings in the release announcements
that this ability was going to go away, and (c) didn't notice that it
was actually *broken* for much of that time.
So...I'm thinking, not a big deal.
++++> telnet. still has problems when (a) connecting from cygwin telnet
client to cygwin telnet server, AND (b) the cygwin telnet client is
running in a cmd box. All other permutations seem to be fine. I'll
track this problem down eventually, but see...
None of the utilities in inetutils have been compiled to support IPv6.
They are IPv4 only. (However, they can be launched from xinetd in IPv4
mode by using the
flags = IPv4
option -- all of the provided /etc/xinetd.d/ configuration files do this.
FUTURE PLANS
============
I plan to continue "shrinking" the size of the inetutils package by
moving various components to their own packages. Most of the distros
seem to provide these tools separately using separate (e.g.
non-inetutils) source, so I'll follow their lead. Besides, it is in the
distro packages that the "IPv6" patches are to be found.
The goal here is to make each client/server unit individually updatable,
for easier maintenance, and to stick to the bare-bones functionality of
the original inetutils versions (but try to add IPv6 support). There
are many more feature-rich servers and clients out there, but porting
and providing (e.g) telnet-krb5 or vsftpd is not my goal.
The inetutils code was originally derived from the netkit distribution,
so that's the starting point. It helps that most of the linux distros
have stuck with -- and updated -- the original netkit versions anyway,
instead of using the inetutils package. (Except ARCH Linux, which seems
to be moving in the opposite direction).
So, eventually we'll have:
telnet -- based on fedora (netkit) telnet
telnet-server -- ditto
ftp -- based on fedora (netkit) ftp
ftpd -- probably based on tnftpd (aka lukemftpd) [1]
tftp -- probably based on the tftp-hpa client
tftp-server -- probably based on the tftp-hpa server
talk -- based on fedora (netkit) talk
talk-server -- ditto
[1] This appears to be the natural successor to the netkit/bsd-derived
inetutils ftpd -- it's actually an undated version of bsd-ftpd. The
linux distros all appear to have abandoned any netkit-derived ftpd, and
instead provide only the more powerful versions like vsftpd, pro-ftpd,
etc. So...in keeping with the minimalist nature of these inetutils
"replacements", we go with the other inetutils ancestor, bsd-ftpd.
This would leave only the following programs/protocols provided by the
trimmed-down inetutils package:
inetd
syslogd
uucpd
which seems about right to me.
I'll probably do this "shrinking" one client/server at a time, and
release an updated inetutils with each new standalone client/server
package. The next target on the list is telnet/telnetd, which will
allow me to independently address the whole "wierdness in cmd.exe"
problem. I hope.
But...it ain't gonna happen anytime soon, so don't worry about version
thrash.
TEST RESULTS
============
I tested the following cygwin clients:
rlogin, rsh, rcp, rexec, telnet, ftp
--> connecting to linux servers, and to the matching
cygwin servers
I tested the following cygwin servers:
rlogind, rshd, rexecd, telnetd, ftpd
--> running under the inetd superserver AND the xinetd
superserver
--> using linux clients and the matching cygwin clients'
I also tested the "built-in" services provided by the inetd and xinetd
superservers. I all cases I was able to get a working connection. In
all cases that support it (e.g. not telnet) I was able to get a working
passwordless connection (*).
This all assumes a properly configured network:
(1) firewall "holes" (and, on the cygwin machine, "program
exceptions") as needed -- as described in the relevant cygwin
README files.
(2) appropriate .rhosts files on the server machine(s) -- for rsh,
rlogin, and rcp
(3) appropriate .netrc files on the client machine(s) -- for ftp and
rexec (**)
(4) an identd server running on the client machine, with an
appropriate hole in the client's firewall. This is easy enough
for linux clients (apt-get/urpmi/rpm oidentd). However, we don't
yet have a cygwin identd server, so I used a free-as-in-beer
Windows version (see the READMEs).
(*) however, unless you have installed and enabled the appropriate
cyglsa module and registered your password with it, you won't get access
to shared drives in a remote session to a cygwin box, unless you log on
with a password.
(**) for a linux-->cygwin rexec to work, you must either (a) use the
-a option when invoking the rexec client, OR (b) turn off your
linux machine's firewall, entirely. Yes, you read that correctly.
I've said all along the r* protocols were a security nightmare. You
really should be using ssh, scp, and sftp instead...
I've attached my test results. Look for uploads and individual package
release announcements to follow.
--
Chuck
--------------050004050102040804010805
Content-Type: text/plain;
name="servers-testing.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="servers-testing.log"
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.
--------------050004050102040804010805
Content-Type: text/plain; charset=us-ascii
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
--------------050004050102040804010805--
- Raw text -