From: Keith Keller on
On 2010-02-10, The Natural Philosopher <tnp(a)invalid.invalid> wrote:
> J G Miller wrote:
>> On Tue, 09 Feb 2010 18:28:40 +0000, The Natural Philosopher wrote:
>>
>>> everything works except using a local password file to send the password
>>
>> Why are you using passwords and password files, and not ssh with DSA keys
>> (with or without pass phrase protection)?
>
> rsync is encrypted anyway.

I don't believe this is true by default, or specifically that your
rsync call is encrypted. It is if you call it over ssh (e.g., via -e
ssh), or if you tunnel it in some other way. (The password itself may
be encrypted; the man page doesn't specify.)

> and the thing will only accept connections from one IP address. Both at
> the router firewall level on the router, IP tables on the box, and
> indeed on rsyncd itself.
>
> Belt, braces and a safety pin.

But if I'm right and your connection is not encrypted, you're wearing a
belt but no pants. You might want to sniff your rsync session to
determine definitively whether it's encrypted before fully trusting your
rsync pipeline.

--keith

--
kkeller-usenet(a)wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

From: Chris Davies on
The Natural Philosopher <tnp(a)invalid.invalid> wrote:
> rsync is encrypted anyway.

Are you sure? I'd infer from the paragraph (Debian man page) "USING
RSYNC-DAEMON FEATURES [...]" that this is not the case:

Rsync supports connecting to a host using a remote shell [...]. This
can be useful if you want to encrypt a daemon-style transfer's data
[...]

and:

For another way to encrypt a daemon transfer, consider using ssh [...]

Chris
From: The Natural Philosopher on
Keith Keller wrote:
> On 2010-02-10, The Natural Philosopher <tnp(a)invalid.invalid> wrote:
>> J G Miller wrote:
>>> On Tue, 09 Feb 2010 18:28:40 +0000, The Natural Philosopher wrote:
>>>
>>>> everything works except using a local password file to send the password
>>> Why are you using passwords and password files, and not ssh with DSA keys
>>> (with or without pass phrase protection)?
>> rsync is encrypted anyway.
>
> I don't believe this is true by default, or specifically that your
> rsync call is encrypted. It is if you call it over ssh (e.g., via -e
> ssh), or if you tunnel it in some other way. (The password itself may
> be encrypted; the man page doesn't specify.)
>
>> and the thing will only accept connections from one IP address. Both at
>> the router firewall level on the router, IP tables on the box, and
>> indeed on rsyncd itself.
>>
>> Belt, braces and a safety pin.
>
> But if I'm right and your connection is not encrypted, you're wearing a
> belt but no pants. You might want to sniff your rsync session to
> determine definitively whether it's encrypted before fully trusting your
> rsync pipeline.
>
ER..if the password is sent encrypted, and no one else can access the
port, and that password will only work from here, and nowhere else,
what's the problem?


> --keith
>
From: Chris Davies on
The Natural Philosopher <tnp(a)invalid.invalid> wrote:
> Oh, I don't care about encrypting the data.

That's fine by me (it's your data). I was simply querying your belief
that rsync provided an encrypted stream.

Cheers,
Chris
From: Keith Keller on
On 2010-02-10, The Natural Philosopher <tnp(a)invalid.invalid> wrote:
>
> ER..if the password is sent encrypted, and no one else can access the
> port, and that password will only work from here, and nowhere else,
> what's the problem?

The problem is that you implied that you thought the entire rsync
session was encrypted; I wanted to be sure that you knew it was probably
not. (And I would not be positive that your password is well-encrypted;
that is something you might wish to verify if it's important to you.)

--keith

--
kkeller-usenet(a)wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: cat for binary file
Next: Sluggish USB hard drives