Forum Moderators: bakedjake
i am trying to test whether my rsync transfers are encrypted so i installed ethereal, but am having trouble understanding the output. here is a sample:
tethereal -i eth0 tcp port 873 -w -
the output is gobbledook - random characters, etc e.g.
E4a@6Àm>I®:Bbô_§Ìi¥La6Ðr
26 L¤q»
is this good news? i.e. is the data encrypted?
thanks for help!
Probably the easiest way to check would be to do a tcpdump (or whatever) of an unencrypted rsync session, and then one that is encrypted to see what the differences are. Note what's readable in the normal rsync, and what's not. Typically, I don't believe you'll be able to actually garner much information out of an rsync session, due to the fact that it uses binary transfers rather than ASCII, but the initilization (login, etc) are probably plain-text and readable. Probably the most useful capture would be the first 10-20 packets.
HTH!
-MM
i've just been doing exactly that this afternoon - tcpdump, and now realise that the data is not sent encrypted unless i specifically say so.
in one session using a passwordless keypair i could capture no data whatsoever, in the other connecting to an rsync server, i could see very clearly all my /conf files (yikes!) spilling down the screen.
the problem is when connecting to an rsync server using the rsh flag --rsh="ssl -l user", it repeatedly dies on me (apparently a bug according to the rsync mailing lists), so i'm going to see if i can set up using an ssh tunnel.
thanks for answering
>> Update your rsync. rsync has defaulted to using ssh for transport since version 2.6.0 (1 January 2004)...
i am using the newest version.
this means if i simply rsync across to another machine i no longer need to specify "-e ssh" it is on, as you say, by default.
however ssh is *not* used when connecting to an rsync server - (see last mail about sniffing my /conf files).
unfortunately the --rsh="ssh -l user" flag does not work when connecting to a rsync server. i keep on getting the following error: (http://samba.anu.edu.au/rsync/issues.html point 2). even updating to the latest RC did not alleviate this problem. i tried restarting using strace as well, but the error persisted.
it could be that i am just not looking in the right place to track down the error, but one solution would be to tunnel through ssh when connecting to the rsync server...
still a bit confused, but have learned lots today ;-)
thanks for input