rsyncssl

[Karl O. Pinc]

On 01/28/2013 04:24:13 AM, devzero at web.de wrote:
> >The only place that an SSL would make some sense, is if you are 
> going
> to do it to/from an rsync daemon,
>  
> yes, exactly.
>  
>  
> >....but then how would that be "better" than a ssh-only account with
> keys/etc. only allowing the rsync to execute?
>  
> I think that`s far more secure by design, because you won`t allow
> shell-access which needs hardening afterwards. 
>  
> For me it`s like giving someone the key to my house and then trying 
> to
> keep him in the hallway , hoping all the other doors being properly
> closed....
>  
> I feel extremely uncomfortable with allowing other people shell 
> access
> to a box, where they need nothing but filetransfer into some 
> dedicated
> subdir.

Put this at the beginning of the ~/.ssh/authorized_keys line, before
the key:

no-pty,no-agent-forwarding,no-port-forwarding,no-user-rc,no-X11-
forwarding,command="rsync --server --daemon ." 

Yes, you do have to lock them out of shell, but once you know
how to do it it's painless to repeat at will.

On the other hand the documentation for the rsync command to use
in this circumstance could be better.  I recall figuring it out
from the man pages but can't at the moment find anything to point
to in the docs which are succinct, clear, and obvious.
That might mean there's now a better way to do it.  Others
may chime in.

And of course you're free do use another method; a separate vpn
like openvpn would be the way I would go.  Trying to build
everything into a single tool, like rsync, is the wrong way.
Instead plug together versatile components.  (It's the Un*x
way!  :)

Meanwhile restricting to nothing but filetransfer into  some dedicated
subdirectory is a completely separate matter than
restricting the shell.  For that, no matter what,
you need to mess around with rsyncd.conf.

Regards,

Karl <kop at meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein