I saw this on the other list today and became intrigued. How does this transfer
and encryption work?
Forwarded Message
Subject:[Bug 4615] encryption with rsync: using ssh's algorithms?
Date: Sun, 26 Jul 2020 01:19:57 +
From: just subscribed for rsync-qa
https://bugzilla.samba.org/show_bug.cgi?id=4615
Wayne Davison changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
On 11 Jan 2018 03:29, H via rsync wrote:
Is anyone using client-side encryption of files before transferring them
to a cloud server using Rsync? I am running CentOS.--
A solution could be EncFS in reverse mode.
Ben
--
Please use reply-all for most replies to avoid omitting the mailing list
On 18-01-10 21:29:18, H via rsync wrote:
Is anyone using client-side encryption of files before transferring them to a
cloud server using Rsync? I am running CentOS.
Yeah, in some cases I use borgbackup then rsync the borg repository
over.
--
Please use reply-all for most replies to avoid
Is anyone using client-side encryption of files before transferring them to a
cloud server using Rsync? I am running CentOS.--
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
https://bugzilla.samba.org/show_bug.cgi?id=4615
--- Comment #2 from Shachar Shemesh ---
What you're asking for is currently possible with an external utility, called
rsyncrypto (http://rsyncrypto.lingnu.com). It, in fact, does not require you to
trust the server you're storing your backups on.
-
Matthias ---
This is probably not so easy, since the keys which are used for encryption
during an SSH session are negotiated in advance to it, are unique for the
session (used only once) and get discarded when the session terminates.
Up to my knowledge, rsync does not get in "contact" with the
Consider an alternative solution: s3ql
Ed W
--
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
>> Which operating system are you running on the system which currently has
>> your personal documents?
>>
>
> Ubuntu/Debian
Do you know if there is a virtual file system encryption system which breaks
the data into bands? I know that Mac OS X has support for bre
online...
Do you think encryption is needed?
How to use encryption with rsync?
Which operating system are you running on the system which currently has your
personal documents?
Ubuntu/ Debian.
~D
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubs
On 08/30/2011 10:09 AM, milu...@s3rsync.com wrote:
Hello,
You can use rsync friendly file encryption before you start your rsync
session.
Take a look at murk
http://murk.sourceforge.net/
and rsyncrypto
http://sourceforge.net/projects/rsyncrypto/
Thanks. But those projects doesn't
Hello,
You can use rsync friendly file encryption before you start your rsync
session.
Take a look at murk
http://murk.sourceforge.net/
and rsyncrypto
http://sourceforge.net/projects/rsyncrypto/
Regards,
Milutin Voinivich
s3rsync.com
On 08/28/2011 07:35 PM, Dirk wrote:
Hi,
I have a
I think Dirk was asking about securing the *DATA* on the remote server -
not the *TRANSPORT*
I'd recommend encfs. It has a "--reverse" option which allows you to
mount a data tree and the new mount shows up with encrypted filenames
and content. rsync that to the remote server, and even the local
s
In case the original poster needs a little more information on setting up rsync
with ssh, a search on
rsync ssh-keygen
will turn up a number of examples/tutorials.
I don't recall which one I originally followed, but after setting it up, I saw
that it was easier and had less maintenance overhea
#x27;t want have to have your
> personal docs online...
>
> Do you think encryption is needed?
>
> How to use encryption with rsync?
>
>
> Thanks in advance,
>
> ~D
> --
> Please use reply-all for most replies to avoid omitting the mailing list.
> To unsubscribe
Hi,
I have a small server at home. I like to put it 'online' and secure it
as good as possible. The counterside of putting your personal backups on
a server is that it might get hacked... and you don't want have to have
your personal docs online...
Do you think encryption is
Milutin Voinivich wrote:
How to use murk when rsync entire directory?
I expect in conjunction with find.
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
r the remote backup to be encrypted locally so one could
backup to a hostile host.
That limits your options.
one would think. For now, lets go with the plaintext push form of
rsnapshot. as for encryption, I think it would be possible (assuming
mods to rsync) to do rsync encrypted copies.
ts go with the plaintext push form of
rsnapshot. as for encryption, I think it would be possible (assuming
mods to rsync) to do rsync encrypted copies.
http://murk.sourceforge.net/
Its an encryption program, for the Unix command line, that is setup to allow
rsync to transfer the encrypted o
s encrypt the files, and then run rsync on
the encrypted result. Touting my own horn here, have a look at
rsyncrypto (http://sf.net/projects/rsyncrypto) for an encryption scheme
that does not totally destroy rsync's wire efficiency.
>
>
> Thanks.
>
>
>
> Brad Farrell
Date: Mon, 12 Jun 2006 18:01:34 -0400
From: Matt McCutchen <[EMAIL PROTECTED]>
On Mon, 2006-06-12 at 17:51 -0400, [EMAIL PROTECTED] wrote:
> The right solution is probably to run an encrypted filesystem on the
> machine that holds the backups, and of course to use ssh getting t
On Mon, 2006-06-12 at 17:51 -0400, [EMAIL PROTECTED] wrote:
> The right solution is probably to run an encrypted filesystem on the
> machine that holds the backups, and of course to use ssh getting the
> files there.
That isn't enough if the department heads don't trust the backup machine
to trans
Then again, the data is saved decrypted on the destination disk. Maybe
the files should be individually encrypted with a symmetric algorithm on
the source before transmission. This could be done with either a script
or the --source-filter option provided by an experimental rsync patc
symmetric algorithm on
the source before transmission. This could be done with either a script
or the --source-filter option provided by an experimental rsync patch.
Note that typical encryption algorithms prevent incremental transfer
from identifying unchanged portions of a file; rsyncrypto does
On Mon, 12 Jun 2006, Brad Farrell wrote:
> Is there a way with rsync to encrypt data at the source before
> transmitting? Not talking about the actually transmission, but the data
> itself. I've got a few department heads that want their data secured
> before it leaves their computer so that n
Hi there
Is there a way with rsync to encrypt data at the source
before transmitting? Not talking about the actually transmission, but the data
itself. I’ve got a few department heads that want their data secured
before it leaves their computer so that no one in the office can access
oment.
I think it would be nicer if some more verbosity is introduced (for
example in the case of the src and dst being identical, write something
to stdout, or at the end of encryption, to write 'n files encrypted' or
something of that sort)... I might actually implement them for my
Julian Pace Ross wrote:
> Thanks everyone for your feedback.
> Seems to me that Alex explained the issue with this perfectly.
I'm afraid that Alex's explanation does not take into account
rsyncrypto's algorithm. If you encrypt two versions of a file, changed
in the first bit of the file between t
Thanks everyone for your feedback.
Seems to me that Alex explained the issue with this perfectly.
However, having said that, it seems that rsyncrypto is a possible candidate to simplify this in an rsyncrypto+rsync setup.
I downloaded it and spent a few minutes trying to make it work, but I didnt m
Hello,
Take a look at Rsyncrypto, rsync friendly file encryption
http://sourceforge.net/projects/rsyncrypto
The file are encrypted befor it rsync.
Regards,
Milutin Voinivich
http://www.nasbackup.com/
**
Julian Pace Ross wrote:
Hi all,
I recently came across a possible requirement of
yption will have to take place before transmission
> anyway. Else you do rely on an uncorrpted rsync on the remote side.
>
> My solution for that problem is outside of rsync. I am using an
> encrypted filesystem where encryption takes place on the local side and
> the actual storage
have
implemented in a backup scenario. If you’re interested, please email me directly.
Alex
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Julian Pace Ross
Sent: Sunday, April 16, 2006 12:44
PM
To: rsync@lists.samba.org
Subject: Encryption
Hi all,
I
Else you do rely on an uncorrpted rsync on the remote side.
My solution for that problem is outside of rsync. I am using an
encrypted filesystem where encryption takes place on the local side and
the actual storage is accessed via the network. rsync itself is a local
(file only) operation t
Hi all,
I recently came across a possible requirement of backing up certain files on a remote server ... in an encrypted format.
This got me seriously thinking about the possibility of doing such a thing with rsync.
I am not too knowledgable about encryption and the mechanisms of the rsync
Gary-
Shachar Shemesh
has created an AES encryption module that
generates RSync friendly encrypted files.
Google his name and you should be able to
find it.
- K
Original Message
>
I am using a SSH tunnel for transit, so just
the backup sit
, the symmetric
encryption key for the file, as well as three parameters used to
determine CBC resets. This information is enough to make a repeated
encryption of the same file (modified or not) identical enough to the
original that rsync will manage to pick up just the differences. This
52
l Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Friday, 13 May 2005 2:43 PM
> To: [EMAIL PROTECTED]
> Cc: rsync@lists.samba.org
> Subject: Re: Encryption
>
>
> > Hi All,
> >
> > I am using rsync to backup our office server to our Inter
> Hi All,
>
> I am using rsync to backup our office server to our Internet server (RHE).
> As an association for doctors we are looking at providing a backup
> service
> for their practices using rsync. As it would be patient data it would need
> to be encrypted. I have found a few options, namely
Hi All,
I am using rsync to backup our office server to our Internet server (RHE).
As an association for doctors we are looking at providing a backup service
for their practices using rsync. As it would be patient data it would need
to be encrypted. I have found a few options, namely
esync
wurt
> I've been thinking about adding the capability to store files compressed
> and/or encrypted on either side of the rsync transfer. Let's say there's
> a storage space provider. I want to store my files on that server
> compressed (so I don't use more paid space than I need), and encrypted
> (s
jw schultz wrote:
Read the list archives. This has been talked to death.
Amen.
Most recently, Martin Langhoff has spoken of doing some work
on using sender-side filtering that sounds promising. There
is also a receiver-side patch out there with the performance
issues you mention.
I've narrowe
On Mon, Jul 28, 2003 at 05:33:13AM +0200, Vaclav Dvorak wrote:
> Hello folks!
>
> I've been thinking about adding the capability to store files compressed
> and/or encrypted on either side of the rsync transfer. Let's say there's
> a storage space provider. I want to store my files on that serve
ce than I need), and encrypted
(so they can't read my data).
I don't know much about encryption, but I suppose that there are some
ciphers that are reasonably strong and don't have the same problem like
gzip (that a single changed byte in the middle of the file affects the
contents of
Introducing
DIGITAL TAPLOCK our Always Encrypted Hardware & Software
Solution.
I extend a warm
welcome for you to look at our line of corporate and executive data encryption
software and hardware devices at http://www.tapsec.com
OpenPGP
Encryption RFC
> | That would lessen encryption security, of course.
> All encryption is done in chunks, the size varies of course, usually
> between 1 and 256 bits.
Of course, but even if block ciphers are usually used to encode data,
they are usually used in OFB or other feedback mode that conver
On Thursday, June 06, 2002 09:55:00 AM +0200 Lapo Luchini <[EMAIL PROTECTED]>
wrote:
+--
| >
| >
| > encript the data in chunks, where the chunk boundaries are determined
| > by the
| >
| >
| That would lessen encryption security, of course.
+-X8
All encryptio
>
>
>encript the data in chunks, where the chunk boundaries are determined by the
>
>
That would lessen encryption security, of course.
--
Lapo 'Raist' Luchini
[EMAIL PROTECTED] (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)
--
To unsubs
On Wed, Jun 05, 2002 at 03:33:23AM -0700, 'jw schultz' wrote:
> On Wed, Jun 05, 2002 at 12:21:18PM +0200, C.Zimmermann wrote:
> > >
> > > If you want them stored on the destination encrypted you
> >
> > Yes, that?s it. The owner of the source files will be sure, that no one
> > else can read his
s REAL usefullness it's that uit
> > examines the content of the file to send just what is needed,
> > differently from other mirroring software.
>
> But beside this rsync offers the mechanism for incremental mirroring on
> file bases over the network, so I think it makes sence
hat is needed,
> differently from other mirroring software.
But beside this rsync offers the mechanism for incremental mirroring on
file bases over the network, so I think it makes sence to enhance rsync
with the encryption option on destination files.
Its better than "tar -cvf - / | pgp | ssh use
On Wed, Jun 05, 2002 at 06:45:44PM +0800, Adrian Ho wrote:
> On Wed, Jun 05, 2002 at 03:33:23AM -0700, 'jw schultz' wrote:
> > As you have said rsync normally just looks at the modification date
>
> And the file size. This check, to the best of my knowledge, cannot be
> turned off.
Yes. I reme
On Wed, Jun 05, 2002 at 03:33:23AM -0700, 'jw schultz' wrote:
> As you have said rsync normally just looks at the modification date
And the file size. This check, to the best of my knowledge, cannot be
turned off.
- Adrian
--
To unsubscribe or change options: http://lists.samba.org/mailman/li
are encrypted i would use the -w option.
Enjoy
>
> Bye Clemens
>
>
>
>
> > will need to keep them encrypted on the source. Rsync won't
> > be able to compare an encrypted (cyphertext) file with an
> > unencrypted (plaintext) one. For rsync to suppo
>
>
>I thought, rsync only looks at the modification date of a file and
>decides whether to backup this file or not.
>
By default, it does not, in fact it's REAL usefullness it's that uit
examines the content of the file to send just what is needed,
differently from other mirroring software.
--
or not. In this case, the backup
could be stored encrypted.
Bye Clemens
> will need to keep them encrypted on the source. Rsync won't
> be able to compare an encrypted (cyphertext) file with an
> unencrypted (plaintext) one. For rsync to support encryption
> it would need to
On Wed, Jun 05, 2002 at 11:42:12AM +0200, C.Zimmermann wrote:
> We need to encrypt files before transferring them to the destination
> Host for security reasons.
> Encryption must be strong: IDEA, 3DES or similar.
> One way would be the integration of PGP into rsync.
>
>
>
>
>Is there any PGP integration into rsync available ?
>
>
No, but there's OpenSSH... quite what you're searching for =)
http://www.openssh.org/
--
Lapo 'Raist' Luchini
[EMAIL PROTECTED] (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)
--
To unsubscribe or change option
We need to encrypt files before transferring them to the destination
Host for security reasons.
Encryption must be strong: IDEA, 3DES or similar.
One way would be the integration of PGP into rsync.
Is there any PGP integration into rsync available ?
Thank´s Clemens
--
To unsubscribe or
using rsync
> > > in non daemon mode with SSH? I have considered building SSH to not use
> > > encryption, but I was thinking rsync in daemon mode might obviate the
> > > need to have to use SSH if it can still be made secure.
> >
> > Unfortunately, the answer
ing SSH to not use
> > encryption, but I was thinking rsync in daemon mode might obviate the
> > need to have to use SSH if it can still be made secure.
>
> Unfortunately, the answer is no. The rsync daemon can protect access with
> passwords that are not sent in the clear over the ne
mote
> machine):
>
> rsync --delete --rsh ssh --rsync-path /path_to_rsync/rsync -rlpt
> sourcedir remote_host/target_dir/
>
> The problem, however, is that due to the large size of the data, and the
> slowness typically suffered under encryption, the remote machine crawls
> to a halt or
IL PROTECTED]
cc: (bcc: Tim Conway/LMT/SC/PHILIPS)
Subject:Question on encryption
Classification:
I am not currently subscribed so please email me below.
First, my only experience with rsync has been older versions (e.g.
1.7.x) which did not allow daemon mode
o not use
> encryption, but I was thinking rsync in daemon mode might obviate the
> need to have to use SSH if it can still be made secure.
Yes - you don't need to run ssh to use rsync in daemon mode. The
authentication mechanism uses a challenge/response so the password is
not sent over
hat due to the large size of the data, and the
slowness typically suffered under encryption, the remote machine crawls
to a halt or is seriously impaired. Working with small numbers of files
or infrequent mirrors, the encryption is not a problem, but it gets to
be a burden when you're doing thi
> converse among themselves. If data is buffered up into blocks they
If you're using zlib on the streams you already *have* sufficient
packetization...
over the whole connection, or at least a whole packet. If
>we allow that, we might have to worry about TCP spoofing,
>man-in-the-middle, and many other things.
TCP spoofing is beyond the scope of end-to-end encryption. Man in the middle
you've taken care of by using the password, whic
On 29 Oct 2000, Pierre Abbat <[EMAIL PROTECTED]> wrote:
> The attacks on synchronous stream ciphers (not to be confused with
> self-synchronizing stream ciphers, which are different sort of
> animal) are of the sort where Mallory flips a bit, not knowing what
> the plaintext is, but knowing that
On 30 Oct 2000, "Mark W. Eichin" <[EMAIL PROTECTED]> wrote:
> Instead of making up some hashing key-generation method, please look
> at RFC2104 "HMAC" (and the six or seven followup rfc's on specific
> instantiations.)
>
> Also, for rsync, I don't see why you'd particularly want a stream
> cipher
Instead of making up some hashing key-generation method, please look
at RFC2104 "HMAC" (and the six or seven followup rfc's on specific
instantiations.)
Also, for rsync, I don't see why you'd particularly want a stream
cipher (it isn't interactive, you have "large" packets to work with)
and I mig
>Z number of people will use stream cyphers when they really should be
>using ssh, because there are active attackers on the network and the
>data is security-critical. This despite that the documentation will
>still recommend using SSH as a first choice.
The attacks on synchronous stream cipher
of people will be able to use rsync when previously the work
to get integration with SSH was more than they cared to spend. (See
the other messages in this thread.)
Y number of people will now use encryption when previously (for
performance or simplicity reasons) they used unencrypted daemon mode.
On Sun, Oct 29, 2000 at 02:54:26PM +1100, Martin Pool wrote:
> On 28 Oct 2000, Nicolas Williams <[EMAIL PROTECTED]> wrote:
> > My guess is that if the SSHv2 spec issues are cleared up then SSHv2 is
> > the best possibility for rsync. I don't mean using SSH with rsync as is
> > done now, but rather
On 29 Oct 2000, Martin Pool <[EMAIL PROTECTED]> wrote:
> Although I would prefer a cypher with a nonproprietary design, RC4
> does seem to be widely used and trusted. Schneier also mentions SEAL;
> I'll look at it later.
It turns out that SEAL is patented (patent pending?) by IBM, so it's
even
On 28 Oct 2000, Nicolas Williams <[EMAIL PROTECTED]> wrote:
> If I may I'd like to suggest an alternative: use Diffie-Hellmann for the
> key exchange and use the DH key as the symmetric encryption key. This
> gives you anonymous encrypted sessions. Add an authentication featu
the complexity of splitting
up into blocks. I guess we could use it in OFB mode to generate a
keystream, but I feel a little uncertain about doing that and I think
it would be quite slow.
Schneier also says RC4 is about ten times faster than
comparably-strong block cyphers. Together with the cost
> Add allow RSA identification only.
Thanks - I didn't see this option.
> Only because you didn't read the manpage. The principle is obvious!
The principle is. The manpage isn't. The manpage didn't help at all with
compiling and installing ssh on Win95/98/NT/2000. It was reasonably
straightf
d like to suggest an alternative: use Diffie-Hellmann for the
key exchange and use the DH key as the symmetric encryption key. This
gives you anonymous encrypted sessions. Add an authentication feature
(basic, GSS-API, SASL, whatever) and you have authenticated encrypted
sessions.
See the curre
On 28 Oct 2000, Rich Salz <[EMAIL PROTECTED]> wrote:
> > However, I don't think SSL will cope with two fork'd processes trying
> > to do SSL simultaneously, because the library assumes complete control
> > over the local end of the socket.
>
> OpenSSL doesn't *have* to work that way, it's just th
ronization, the remainder of the stream will be
unrecoverable. However, we can quite reasonably count on TCP to avoid
doing that. (It's not like we're running over a plain async serial
line.) After all, if TCP were to lose bytes then plain rsync would be
corrupted and unrecoverable
> However, I don't think SSL will cope with two fork'd processes trying
> to do SSL simultaneously, because the library assumes complete control
> over the local end of the socket.
OpenSSL doesn't *have* to work that way, it's just that the default
implementation that most people use works that w
I'd like to add my voice to the "yes please" crowd for built-in transport
and encryption for rsync. I use rsync primarily for mirroring purposes,
and hence have to run it as root at both ends. To have it run via ssh
automatically at night, I had to have an empty passphrase for
>> I honestly don't think it's worth it. Anyone who can compile can
>> compile (and install) ssh.
>
>Possibly it is not worthwhile after all -- I always knew it would be
>worse than SSL but the idea of completely cutting out the transport
>problems was tempting.
>
>If it turns out that there ar
On 27 Oct 2000, Bennett Todd <[EMAIL PROTECTED]> wrote:
> 2000-10-27-21:26:36 Martin Pool:
> But OpenSSL isn't just the reference SSL lib these days, it's also
> the reference general-purpose crypto library. OpenSSH doesn't talk
> SSL, it just uses the crypto routines out of OpenSSL. In fact,
> O
On 27 Oct 2000, Bennett Todd <[EMAIL PROTECTED]> wrote:
> 2000-10-27-22:02:28 Martin Pool:
> > In the end, perhaps offering weak security as an alternative is a
> > bad idea, as people may be tempted to use it rather than doing a
> > little more work to install ssh. On the other hand, sometimes
>
key
> > > exchanges using a tougher key.
> >
> > You seem to think I was talking about using xor with a constant key,
>
> Not really, as you can see.
Then I don't understand how a chosen-plaintext attack could give away
the encryption key.
> > in which case
On 27 Oct 2000, "Peter T. Breuer" <[EMAIL PROTECTED]> wrote:
> Rsync does its own compression, which is
> encryption, as you don't know where the compressed bits come from even
> if you guess the compression used.
It's true that existing and rearranged data is
On 27 Oct 2000, Dave Dykstra <[EMAIL PROTECTED]> wrote:
> There's been a lot of talk about incorporating openssl into rsync but
> it's never been done.
My previous message explains why it seems hard, but perhaps I've just
missed something.
> I'm actually much more interested in the active attac
On 27 Oct 2000, Neil Schellenberger <[EMAIL PROTECTED]> wrote:
> I'm absolutely no expert on it (e.g. never programmed with it), but
> perhaps you could simply use OpenSSL (which is, after all, what
> OpenSSH is implemented on top of anyway). Then you'd get high grade
&
x27;m looking at adding built-in stream encryption, so that we can give
people some privacy even if they can't use ssh. In combination with
the challenge-response password system, this will mean that both
passwords and rsync data will be protected from snooping on the wire.
I'm not trying
89 matches
Mail list logo
