3

We are trying to implement a safe rsync for backups between 2 servers. We are trying by all means to avoid having root access with no passwords between the 2 systems and if any just do that for an specific user.

I understand this has issues with permissions of the backed up files. I've read here in serverfault and also on this site about using fakeroot and about the "PermitRootLogin forced-commands-only" option of SSH server but still can't figure out what is the most logical and reasonable option from a security point of view. We do not want a root user to automatically have root access on the other machine without a password. Not sure if we are just to paranoid about it but as I suppose this is something pretty usual any feedback would be mostly appreciated.

  • Does the PermitRootLogin forced-commands-only with a pair of keys for no password be good enough? Does this need an specific list of allowed commands on the destination server (i.e rsync)?
  • Would the fakeroot option work (mainly data backups in our case) and if so... how is it combined with the rsync command?
  • Can we have an rsync user with sufficient permissions on both systems so the passwordless rsync works fine?

Many thanks.

Community
  • 1
luison
  • 282
  • 1
  • 7
  • 22

1 Answers1

2

You are right that passwordless root login on either your live machine(s) or your backup machine(s) is a bad idea - if someone gains access to one side they immediately have access to the other so can damage both your live data and online backups at the same time.

The fakeroot option should work fine if your to-be-backed-up servers are pushing updates to those storing the backups and you just need to add --fake-super to the rsync command line and make sure that the filesystem at the receiving end supports extended attributes.

Another option is to introduce an intermediate machine that both the live and backup servers have key-base root logins to. That was the live machines can push backups to the intermediate machine with rsync and afterwards the backup machines can pull them down, without either live or backup machines being able to login to each other at all, never mind as root. The intermediate machine doesn't need to be able to authenticate with either live or backup servers either. The intermediate server only needs enough space to hold the ltest versions of everything (i.e. the data stored on the backup servers including snapshots from different times could be several times larger than the intermediate server can store.

Of course it goes without saying that as well as disallowing key-based root login between servers you make sure that the root (and other) passwords all differ from machine to machine too.

David Spillett
  • 22,754
  • 45
  • 67
  • Thanks... we are testing the --fake-super option as yes we are initially "pushing" from source to backup. We still get sort of chown errors. When you say "make sure that the filesystem at the receiving end supports extended attributes" not sure if the backup end needs any special privileged account or rsync type command. – luison Feb 12 '10 at 13:44
  • You should add the extra detail to your question. Specifically when you say "we still get sort of chown errors" you should tell us what the error reported actually is, in full. IIRC the fake-super option should not need special user privileges - the whole point of it is to remote the need to run as a particularly privileged user. – David Spillett Feb 12 '10 at 16:30
  • This is the command we issue and the feedback we get. This is to users "rsync" with SSH paswword-less setup on both servers which seem to work fine: WITH FAKE-SUPER rsync -e ssh -avz --rsync-path="rsync --fake-super" /home/webs/test/html/ rsync@destinationhost.com:/home/webs/test/html Warning: remote port forwarding failed for listen port 3306 rsync: failed to set times on "/home/webs/test/html/.": Operation not permitted (1) rsync: failed to write xattr user.rsync.%stat for "/home/webs/test/html/alsurpinfo.php": Operation not supported (95) – luison Feb 15 '10 at 15:22
  • I've never used `--fake-super` myself. Could it be specified client-side with something like `rsync -avz --fake-super /home/webs/test/html/ rsync@destinationhost.com:/home/webs/test/html`? I don't know what the port forwarding warning is, either running rsync with --rsync-path is making it try function this way around or you have something in the serverside rsyncd.conf that is taking action... – David Spillett Feb 15 '10 at 21:44
  • Thanks. We'll keep testing. The port-forward error also suprised me as it's got to do with a tunneling we do for MySQL. I understand there is no tunnel need in this case as it's suppose to be just a command. Alternatively our mistake might be that rsync is not running as a service as I understand on the destination host and this might be an issue when not running the commands as root. We well be trying the root access with forced-commands-only to see if that is more succesful. – luison Feb 16 '10 at 09:19