Forum Moderators: bakedjake

Message Too Old, No Replies

understanding tethereal output?

         

jamie

7:05 am on Sep 8, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



hi,

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!

MattyMoose

4:31 pm on Sep 8, 2004 (gmt 0)

10+ Year Member



It depends if you've enabled ASCII output in ethereal. Never user "tethereal" before, mostly tcpdump.

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

jamie

4:42 pm on Sep 8, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



hi matty,

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

py9jmas

4:58 pm on Sep 8, 2004 (gmt 0)

10+ Year Member



Update your rsync. rsync has defaulted to using ssh for transport since version 2.6.0 (1 January 2004). Since then there have been two security problems found (only affecting those who run rsync as a daemon, but even so).

drbrain

5:43 pm on Sep 8, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



You want something like:

rsync -e ssh localpath user@remotehost:remotepath

jamie

6:08 pm on Sep 8, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



hi py9jmas and dr. brain

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