daemon-server via SSH (was Re: new rsync release needed soon?)

[Dave Dykstra]

On Wed, Jul 31, 2002 at 05:54:29PM -0700, Wayne Davison wrote:
> On Wed, 31 Jul 2002, Dave Dykstra wrote:
> > The patch that I'd most like to see get in JD Paul's patch for using
> > SSH and daemon mode together.
> 
> I've completed my mods to get this updated to the latest CVS version and
> then checked it all in.  Since things had changed quite a bit, I applied
> the patch by hand and then compared my changes to the original patch to
> ensure that I did a good job.
> 
> I did leave out one thing that I had a question about in main.c:  the
> code that was looking for a -l option in the remote-shell command.  If
> the user specifies a username in both the host-spec and in their ssh
> command, do we really want to silently eliminate one of them?  Or should
> we maybe complain and fail?  I think I might prefer to let the remote-
> shell command run and let it complain about the two -l options (if
> that's what it wants to do), but I could be convinced otherwise.


I'm pretty sure that we discussed that issue when the patch was developed,
and there are some cases where you want to use both.  Yes: the notion of a
userid in an rsync server module is not the same thing as the ssh -l userid;
the former specifies which password to use in a secrets file, and the
latter specifies which userid to log in as.  I think the way JD did it was
the compromise we agreed on: if a userid is specified only with
userid at hostname, it should be used for both purposes, but if the -e command
includes -l it should override the login userid only.  This is documented
in the man page at "CONNECTING TO AN RSYNC SERVER OVER A REMOTE SHELL PROGRAM".


> I've tested normal rsync operations to ensure that it is still working
> right, but not daemon mode (which I don't normally use).  If someone
> could help out with the testing, I'd appreciate it.

I tried it out with an example like
    rsync -e ssh --rsync-path=.... /etc/motd localhost::
and the first thing one runs across is that the remote side tries to open
/etc/motd.conf and reports an error only to the syslog.   The man page
explains that the way to set a different config file is by using ssh
and authorized_keys and set the forced command with a --config-file 
option.  I suggest we have rsync --daemon first look for $HOME/rsyncd.conf
before looking for /etc/rsyncd.conf.  That will be a modification to the
server side, but other than that a cool thing about this patch is that it
seems to work quite well with older versions of rsync on the server side.

Also, I don't know how clean it will be to implement, but I think it will
save us a lot of questions if we let that initial error message about not
being able to open /etc/rsyncd.conf show up on the and the client and not
go only to syslog.

One thing that did not work for me is the "hosts allow" and presumably
"hosts deny": it says "@ERROR: access denied to testdir from unknown ()".
There was code on the server side that's reads $SSH_CLIENT for the IP
address and set "remote.shell.connection" as the host name.  It was
switching on is_a_socket() though, and at least in my case that is
returning true for the ssh connection.  I went ahead and developed a fix
for that and submitted it to CVS.  Any time $SSH_CLIENT is specified, I use
that for the client IP address, and I look up the real name with
getnameinfo().  I included code I thought would be needed for IPv6 but
haven't tested that part yet, I hope somebody else can.

- Dave Dykstra