similar to: 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

-----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. >

Hello. Please see http://unix.stackexchange.com/a/66702. I would like to have confirmation whether or not rsync verifies the transferred files' integrity at the target location by checksumming as advertised in the manpage: """Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is

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

> 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

> You are missing the point of the checksum. It is a verification that > the file was assembled on the target system correctly. The only > post-transfer checksum that would make any sense locally would be to > make sure that the disk stored the file correctly which would require > a flushing of the cache and a re-reading of the file. Rsync has no > capability to do this

On Wed, Dec 3, 2014 at 9:40 AM, Tomasz Chmielewski <mangoo at wpkg.org> 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

This is not strictly Dovecot question, but a more general IMAP one. I'm running a Dovecot server and have a user who is claiming that some email sent to him, say, on 30 May, showed up in his mailbox on 02 Jun. I've checked Postfix logs, and the message was correctly received on 30 May and passed to Dovecot. A similar issue happens every few days. This leaves me with two possibilities:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You are missing the point of the checksum. It is a verification that the file was assembled on the target system correctly. The only post-transfer checksum that would make any sense locally would be to make sure that the disk stored the file correctly which would require a flushing of the cache and a re-reading of the file. Rsync has no capability

-----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