On Friday 31 August 2001 23:21, you wrote: Again a late reply... here goes
- Maarten J H van den Berg wrote on Mon, Aug 06, 2001 at 18:29 +0200:
Instead, the best (and almost completely secure in every aspect) is to use an RSA certificate, and put the command, client-IP etc. which the client uses inside the authorized_keys file on the server: That will make sure that when using that specific certificate, the client is FORCED to run EXACTLY the command specified.
It's not trivial to configure access via rsync to some backup server. rsync needs root privileges to keep ownerships. Rsync as root may overwrite any file. The authorized_keys wrapper needs to filter the directory arguments (keep track on /backup/../etc/shadow and so on).
Agreed on the 'must run as root' part of course. The reason I could not use tarballs instead, as other people mentioned, is a) I do not have enough diskspace on the source-machine to write the tarball, and more importantly b) one cannot do incremental backups when using tarballs (at least not without some hacks). But back to the issue; you say rsync should filter paths and so on, I beg to differ (Caveat: If I'm not overlooking something) Look at my config. This is what the client commandline looks like: rsync -e ssh -ogptLrcv --stats --partial --exclude=logs/ --safe-links /etc/foobar root@www.xxx.yyy.zzz:/home/backups/Host-AAA/ And this is the server-side exerpt from authorized_keys: command="rsync --server -vLogtprc --partial --safe-links . /home/backups/Host-AAA/",no-port-forwarding,no-X11-forwarding,no-agent-forwarding 1024 35 123456789....................123456789 root@aaa.bbb.ccc.ddd Okay, now try to run a doctored backupcommand like: rsync -e ssh -ogptLrcv --stats --partial --exclude=logs/ --safe-links /etc/foobar root@www.xxx.yyy.zzz:/home/backups/Host-AAA/../../../ ...And do an ls on the www.xxx.yyy.zzz server: ls -la /foobar ls: foobar: No such file or directory ls -la /home/foobar ls: foobar: No such file or directory ls -la /home/backups/foobar ls: foobar: No such file or directory ls -la /home/backups/Host-AAA/foobar -rw------- 1 root root 138 Jun 16 2000 /home/backups/Host-AAA/foobar So you see, as I wrote earlier, the SERVER IS ENFORCING the command which the client tries to run. (Again, unless I made a mistake that is.) I can try other variations like root@www.xxx.yyy.zzz:/home/../tmp/foobar etc., but in all cases I tried, the file ends up inside the /home/backups/Host-AAA dir, not below. Thus, one could overwrite the backup itself, but never anything else. If you can show me a commandline that does indeed break out of the target dir, I'd be VERY interested to know, needless to say.
Another possibility: the server runs something like tar -cvf - $SOURCES_TO_BACKUP | ssh backup@backuphost cat > host.tar
It seems to me that this would be easier to wrap correctly. No root access to the backup server required.
I commented on the use of tarballs above. It wasn't useable for me at the time. However, If you CAN, this is indeed a safer option. Greetings, Maarten -- Maarten J. H. van den Berg ~~//~~ network administrator van Boetzelaer van Bemmel - Amsterdam - The Netherlands http://vbvb.nl T+31204233288 F+31204233286 G+31651994273