rsync - Dec 2014 - Aw: Re: encrypted rsyncd - why was it never implemented?

from a security perspective this is bad. think of a backup provider who wants to
make rsyncd modules available to the end users so they can push backups to the
server. do you think that such server is secure if all users are allowed to open
up an ssh shell to secure their rsync transfer ?

ok, you can restrict the ssh connection, but you open up a hole and you need to
think twice to make it secure - leaving room for hacking and circumventing ssh
restrictions.

indeed, rsyncd with ssl is quite attractive, but adding ssl to rsync adds quite
some complexity and also increases maintenance work.

for some time there is a ssl patch in the contrib directory, but  i`m curious
why nobody is aware of rsyncssl, which is not a perfect but quite some elegant
solution to support wrapping rsyncd with ssl via stunnel:

http://dozzie.jarowit.net/trac/wiki/RsyncSSL
https://git.samba.org/?p=rsync.git;a=commit;h=70d4a945f7d1ab1aca2c3ca8535240fad4bdf06b

regards
roland


> Gesendet: Mittwoch, 03. Dezember 2014 um 19:19 Uhr
> Von: "Kevin Korb" <kmk at sanitarium.net>
> An: rsync at lists.samba.org
> Betreff: Re: encrypted rsyncd - why was it never implemented?
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> You can run rsyncd over ssh as well.  Either with -e ssh host::module
> or you can use ssh's -L to tunnel the rsyncd port.  The difference is
> which user ends up running the rsyncd.
> 
> On 12/03/2014 12:40 PM, Tomasz Chmielewski wrote:
> > rsync in daemon mode is very powerful, yet it comes with one big 
> > disadvantage: data is sent in plain.
> > 
> > The workarounds are not really satisfying:
> > 
> > 
> > - use VPN - one needs to set up an extra service, not always
> > possible
> > 
> > - use stunnel - as above
> > 
> > - use SSH - is not as powerful as in daemon mode (i.e. read only
> > access, chroot, easy way of adding/modifying users and modules
> > etc.)
> > 
> > 
> > Why was encrypted communication in rsyncd never implemented? Some 
> > technical disagreements? Nobody volunteered?
> > 
> > 
> 
> - -- 
>
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
> 	Kevin Korb			Phone:    (407) 252-6853
> 	Systems Administrator		Internet:
> 	FutureQuest, Inc.		Kevin at FutureQuest.net  (work)
> 	Orlando, Florida		kmk at sanitarium.net (personal)
> 	Web page:			http://www.sanitarium.net/
> 	PGP public key available on web site.
>
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iEYEARECAAYFAlR/VEUACgkQVKC1jlbQAQcE+wCfYD+irslnu/nRool4RPL+KjUC
> J9wAoKmYNAlfpCMlVKYcV+jpW8e0YNF6
> =oUk3
> -----END PGP SIGNATURE-----
> -- 
> Please use reply-all for most replies to avoid omitting the mailing list.
> To unsubscribe or change options:
https://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As far as a backup provider goes I wouldn't expect them to use rsync
over SSL unless that were built into rsync in the future (and has been
around long enough that most users would have it).

I would expect them to either use rsync over ssh secured by rrsync or
rsyncd over ssh with them managing the rsyncd.conf file.  Either way
the server side command would be forced and no other ssh functionality
would be allowed.

The benefit of rsync over ssh secured by rrsync is that it is more
like what rsync users are already used to.

The benefit of rsyncd over ssh would be that the provider would manage
the rsyncd.conf files (1 per user) and could make a web UI to control
certain aspects of it.

I am thinking of something like this with in sshd_config with
whichever ForceCommand they would pick:

Match Group backupusers
  X11Forwarding no
  AllowTcpForwarding no
  ForceCommand /usr/bin/rsync --server --daemon .
  ForceCommand /usr/bin/rrsync-wrapper

Note that a wrapper or modification would be needed for rrsync since
sshd_config doesn't support %u or %h in ForceCommand :(


On 12/03/2014 02:20 PM, devzero at web.de wrote:
> from a security perspective this is bad. think of a backup provider
> who wants to make rsyncd modules available to the end users so they
> can push backups to the server. do you think that such server is
> secure if all users are allowed to open up an ssh shell to secure
> their rsync transfer ?
> 
> ok, you can restrict the ssh connection, but you open up a hole and
> you need to think twice to make it secure - leaving room for
> hacking and circumventing ssh restrictions.
> 
> indeed, rsyncd with ssl is quite attractive, but adding ssl to
> rsync adds quite some complexity and also increases maintenance
> work.
> 
> for some time there is a ssl patch in the contrib directory, but
> i`m curious why nobody is aware of rsyncssl, which is not a perfect
> but quite some elegant solution to support wrapping rsyncd with ssl
> via stunnel:
> 
> http://dozzie.jarowit.net/trac/wiki/RsyncSSL 
>
https://git.samba.org/?p=rsync.git;a=commit;h=70d4a945f7d1ab1aca2c3ca8535240fad4bdf06b
>
>  regards roland
> 
> 
> 
>> Gesendet: Mittwoch, 03. Dezember 2014 um 19:19 Uhr Von: "Kevin
>> Korb" <kmk at sanitarium.net> An: rsync at lists.samba.org
Betreff: Re:
>> encrypted rsyncd - why was it never implemented?
>> 
> You can run rsyncd over ssh as well.  Either with -e ssh
> host::module or you can use ssh's -L to tunnel the rsyncd port.
> The difference is which user ends up running the rsyncd.
> 
> On 12/03/2014 12:40 PM, Tomasz Chmielewski wrote:
>>>> rsync in daemon mode is very powerful, yet it comes with one
>>>> big disadvantage: data is sent in plain.
>>>> 
>>>> The workarounds are not really satisfying:
>>>> 
>>>> 
>>>> - use VPN - one needs to set up an extra service, not always 
>>>> possible
>>>> 
>>>> - use stunnel - as above
>>>> 
>>>> - use SSH - is not as powerful as in daemon mode (i.e. read
>>>> only access, chroot, easy way of adding/modifying users and
>>>> modules etc.)
>>>> 
>>>> 
>>>> Why was encrypted communication in rsyncd never implemented?
>>>> Some technical disagreements? Nobody volunteered?
>>>> 
>>>> 
> 
>> -- Please use reply-all for most replies to avoid omitting the
>> mailing list. To unsubscribe or change options:
>> https://lists.samba.org/mailman/listinfo/rsync Before posting,
>> read: http://www.catb.org/~esr/faqs/smart-questions.html
>> 
- -- 
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
	Kevin Korb			Phone:    (407) 252-6853
	Systems Administrator		Internet:
	FutureQuest, Inc.		Kevin at FutureQuest.net  (work)
	Orlando, Florida		kmk at sanitarium.net (personal)
	Web page:			http://www.sanitarium.net/
	PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlR/ZpYACgkQVKC1jlbQAQcv2wCg5VUHdgqm1qCKMjq2jMS+cYnU
nC0AoJ6n/Pi9+CTAp0r5cPtF8V32y5G4
=CtdG
-----END PGP SIGNATURE-----

> The benefit of rsync over ssh secured by rrsync is that it is more
> like what rsync users are already used to.
i don`t like rsync over ssh in an environemt with users you can?t trust.

from a security perspective, i think such setup is broken by design.

it`s a little bit like giving a foreigner the key to your front door and then
hope that the door in the corridor to your room will be "secure and stable
enough".

some reasons why i think this way can be found here:
https://www.google.de/search?q=ssh+restricted+shell+bypass

regards
roland


> Gesendet: Mittwoch, 03. Dezember 2014 um 20:37 Uhr
> Von: "Kevin Korb" <kmk at sanitarium.net>
> An: devzero at web.de
> Cc: rsync at lists.samba.org
> Betreff: Re: Aw: Re: encrypted rsyncd - why was it never implemented?
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> As far as a backup provider goes I wouldn't expect them to use rsync
> over SSL unless that were built into rsync in the future (and has been
> around long enough that most users would have it).
> 
> I would expect them to either use rsync over ssh secured by rrsync or
> rsyncd over ssh with them managing the rsyncd.conf file.  Either way
> the server side command would be forced and no other ssh functionality
> would be allowed.
> 
> The benefit of rsync over ssh secured by rrsync is that it is more
> like what rsync users are already used to.
> 
> The benefit of rsyncd over ssh would be that the provider would manage
> the rsyncd.conf files (1 per user) and could make a web UI to control
> certain aspects of it.
> 
> I am thinking of something like this with in sshd_config with
> whichever ForceCommand they would pick:
> 
> Match Group backupusers
>   X11Forwarding no
>   AllowTcpForwarding no
>   ForceCommand /usr/bin/rsync --server --daemon .
>   ForceCommand /usr/bin/rrsync-wrapper
> 
> Note that a wrapper or modification would be needed for rrsync since
> sshd_config doesn't support %u or %h in ForceCommand :(
> 
> 
> On 12/03/2014 02:20 PM, devzero at web.de wrote:
> > from a security perspective this is bad. think of a backup provider
> > who wants to make rsyncd modules available to the end users so they
> > can push backups to the server. do you think that such server is
> > secure if all users are allowed to open up an ssh shell to secure
> > their rsync transfer ?
> > 
> > ok, you can restrict the ssh connection, but you open up a hole and
> > you need to think twice to make it secure - leaving room for
> > hacking and circumventing ssh restrictions.
> > 
> > indeed, rsyncd with ssl is quite attractive, but adding ssl to
> > rsync adds quite some complexity and also increases maintenance
> > work.
> > 
> > for some time there is a ssl patch in the contrib directory, but
> > i`m curious why nobody is aware of rsyncssl, which is not a perfect
> > but quite some elegant solution to support wrapping rsyncd with ssl
> > via stunnel:
> > 
> > http://dozzie.jarowit.net/trac/wiki/RsyncSSL 
> >
https://git.samba.org/?p=rsync.git;a=commit;h=70d4a945f7d1ab1aca2c3ca8535240fad4bdf06b
> >
> >  regards roland
> > 
> > 
> > 
> >> Gesendet: Mittwoch, 03. Dezember 2014 um 19:19 Uhr Von:
"Kevin
> >> Korb" <kmk at sanitarium.net> An: rsync at
lists.samba.org Betreff: Re:
> >> encrypted rsyncd - why was it never implemented?
> >> 
> > You can run rsyncd over ssh as well.  Either with -e ssh
> > host::module or you can use ssh's -L to tunnel the rsyncd port.
> > The difference is which user ends up running the rsyncd.
> > 
> > On 12/03/2014 12:40 PM, Tomasz Chmielewski wrote:
> >>>> rsync in daemon mode is very powerful, yet it comes with
one
> >>>> big disadvantage: data is sent in plain.
> >>>> 
> >>>> The workarounds are not really satisfying:
> >>>> 
> >>>> 
> >>>> - use VPN - one needs to set up an extra service, not
always
> >>>> possible
> >>>> 
> >>>> - use stunnel - as above
> >>>> 
> >>>> - use SSH - is not as powerful as in daemon mode (i.e.
read
> >>>> only access, chroot, easy way of adding/modifying users
and
> >>>> modules etc.)
> >>>> 
> >>>> 
> >>>> Why was encrypted communication in rsyncd never
implemented?
> >>>> Some technical disagreements? Nobody volunteered?
> >>>> 
> >>>> 
> > 
> >> -- Please use reply-all for most replies to avoid omitting the
> >> mailing list. To unsubscribe or change options:
> >> https://lists.samba.org/mailman/listinfo/rsync Before posting,
> >> read: http://www.catb.org/~esr/faqs/smart-questions.html
> >> 
> 
> - -- 
>
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
> 	Kevin Korb			Phone:    (407) 252-6853
> 	Systems Administrator		Internet:
> 	FutureQuest, Inc.		Kevin at FutureQuest.net  (work)
> 	Orlando, Florida		kmk at sanitarium.net (personal)
> 	Web page:			http://www.sanitarium.net/
> 	PGP public key available on web site.
>
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iEYEARECAAYFAlR/ZpYACgkQVKC1jlbQAQcv2wCg5VUHdgqm1qCKMjq2jMS+cYnU
> nC0AoJ6n/Pi9+CTAp0r5cPtF8V32y5G4
> =CtdG
> -----END PGP SIGNATURE-----
>

On 12/03/2014 01:37:58 PM, Kevin Korb wrote:
> As far as a backup provider goes I wouldn't expect them to use rsync
> over SSL unless that were built into rsync in the future (and has 
> been
> around long enough that most users would have it).
> 
> I would expect them to either use rsync over ssh secured by rrsync or
> rsyncd over ssh with them managing the rsyncd.conf file.  Either way
> the server side command would be forced and no other ssh 
> functionality
> would be allowed.
<snip>
> I am thinking of something like this with in sshd_config with
> whichever ForceCommand they would pick:
> 
> Match Group backupusers
>   X11Forwarding no
>   AllowTcpForwarding no
>   ForceCommand /usr/bin/rsync --server --daemon .
>   ForceCommand /usr/bin/rrsync-wrapper
> 
> Note that a wrapper or modification would be needed for rrsync since
> sshd_config doesn't support %u or %h in ForceCommand :(
I am using command="rsync --server --daemon ." 
in ~/ssh/authorized_keys.  Correct me if I'm wrong,
but I believe this eliminates the need for %u or %h
and ForceCommand.

It does mean that key based authentication is required,
but this does not seem burdensome for a backup oriented
solution.


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

On Wed, Dec 3, 2014 at 9:20 PM,  <devzero at web.de>
wrote:
> from a security perspective this is bad. think of a backup provider who
wants to make rsyncd modules available to the end users so they can push backups
to the server. do you think that such server is secure if all users are allowed
to open up an ssh shell to secure their rsync transfer ?
For a *start* Those users needed to be properly authenticated,
authorized and accounted (AAA) for. In that case, you can't run rsyncd
*without* passwords and usernames etc. I can't recall that those
passwords are encrypted in anyway, as it needed the unencrypted for
the way it send the password's challenges back and forth.

The next fun part in this way, is that you'll need to create a
stanza/entry for each user and their directories, else you'll be
violating the authorization requirements.
It'll be easy for a couple, but what about the hundreds of users?
> ok, you can restrict the ssh connection, but you open up a hole and you
need to think twice to make it secure - leaving room for hacking and
circumventing ssh restrictions.
Instead of having that at the rsync level?

Yes, ssh is a piece of software that had it share of security
violations, I'll agree, but it'll be much more manageable AAA (imho
and experience) to have the clients' ssh pub-keys inserted into an
authorized keys file with only the /usr/bin/rsync --server (etc.) as
the command that could be executed, in their own home directory (which
is the backup folder for that user) with only that user having
read-write permission in that folder, and the shell of that account
being /bin/true with a bogus /etc/shadow password string, something
like $6$oops$trythisforsha512 or just the plain old *, and you have a
decent security system in place for the backups, using rsync.
> indeed, rsyncd with ssl is quite attractive, but adding ssl to rsync adds
quite some complexity and also increases maintenance work.
Given the above description, I'll ask: Why SSL?
Even better: Which SSL implementation? you don't want the OpenSSL with
all it's troubles, and then GnuTLS also had it's fun of security holes
I recall.

> for some time there is a ssl patch in the contrib directory, but  i`m
curious why nobody is aware of rsyncssl, which is not a perfect but quite some
elegant solution to support wrapping rsyncd with ssl via stunnel:
>
> http://dozzie.jarowit.net/trac/wiki/RsyncSSL
>
https://git.samba.org/?p=rsync.git;a=commit;h=70d4a945f7d1ab1aca2c3ca8535240fad4bdf06b
If that works for you, fine, I just think that ssh does the job well
enough with out having to add undue complexity to rsync
>
> regards
> roland
>
>
>
>> Gesendet: Mittwoch, 03. Dezember 2014 um 19:19 Uhr
>> Von: "Kevin Korb" <kmk at sanitarium.net>
>> An: rsync at lists.samba.org
>> Betreff: Re: encrypted rsyncd - why was it never implemented?
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> You can run rsyncd over ssh as well.  Either with -e ssh host::module
>> or you can use ssh's -L to tunnel the rsyncd port.  The difference
is
>> which user ends up running the rsyncd.
>>
>> On 12/03/2014 12:40 PM, Tomasz Chmielewski wrote:
>> > rsync in daemon mode is very powerful, yet it comes with one big
>> > disadvantage: data is sent in plain.
>> >
>> > The workarounds are not really satisfying:
>> >
>> >
>> > - use VPN - one needs to set up an extra service, not always
>> > possible
>> >
>> > - use stunnel - as above
>> >
>> > - use SSH - is not as powerful as in daemon mode (i.e. read only
>> > access, chroot, easy way of adding/modifying users and modules
>> > etc.)
>> >
>> >
>> > Why was encrypted communication in rsyncd never implemented? Some
>> > technical disagreements? Nobody volunteered?
>> >
>> >
>>
>> - --
>>
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
>>       Kevin Korb                      Phone:    (407) 252-6853
>>       Systems Administrator           Internet:
>>       FutureQuest, Inc.               Kevin at FutureQuest.net  (work)
>>       Orlando, Florida                kmk at sanitarium.net (personal)
>>       Web page:                       http://www.sanitarium.net/
>>       PGP public key available on web site.
>>
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2
>>
>> iEYEARECAAYFAlR/VEUACgkQVKC1jlbQAQcE+wCfYD+irslnu/nRool4RPL+KjUC
>> J9wAoKmYNAlfpCMlVKYcV+jpW8e0YNF6
>> =oUk3
>> -----END PGP SIGNATURE-----
>> --
>> Please use reply-all for most replies to avoid omitting the mailing
list.
>> To unsubscribe or change options:
https://lists.samba.org/mailman/listinfo/rsync
>> Before posting, read:
http://www.catb.org/~esr/faqs/smart-questions.html
>>
> --
> Please use reply-all for most replies to avoid omitting the mailing list.
> To unsubscribe or change options:
https://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html