running rsync as root
 

Ok here's the situation. I have two remote servers that i need to keep updated at work. Rsync was my obvious choice for syncing the remote servers. My current setup has rsync running over ssh with root access to the remote servers. I used ssh-keygen to put a public key on both of the remote servers. SSH passwordauthentication has been set to "No". I need to run my rsync/ssh scripts with root access because I'll be syncing very important system files.

My question is is this a really bad idea? If I try to run an rsync script as a user I get an access denied error to the important system files. Again, both remote servers have had their SSHD configured to only allow private key connections.

The only other option I could think of would be to give a single system user access to the private system files. But that just seems like a bad idea to me.

Also, the scripts that are run are only rwx by the root user and group. So theres no chance of a regular system user modifying the scripts to do something nasty.

Is this setup horribly unsecure or is this sort of thing pretty standard?

Could you tell us in broad terms what you're rsyncing and if it's critical wrt time or otherwise?

/etc
/home
/var/spool/mail
/var/lib/mysql
/var/www
/var/www2

edit:
The in-house mirror is synced every hour like I said. I feel it is very important to have that thing as up to date as possible. If the primary server ever goes down, I don't like the idea of important e-mails sitting in /var/spool/mail without the users knowing about them.

The remote servers get synced a couple of times each day, they're not as big of a priority as the mirror.

is synced every hour like I said.
No you didn't say that.


My question is is this a really bad idea?
Answering in short: yes (no passphrase) but not really (if you take precautions).

As a general remark (just in case) one should NOT use SSH protocol v1 keys anymore unless talking to legacy hosts that don't understand protocol 2. Thinking out loud IMHO separating drop and stash operations would be less of a "risk", but using more stages may introduce complexity ("Complexity is the enemy or security") you may not want to deal with. By separating I mean that you try to avoid the need for remote root account access. Root would copy the files to a tree in a holding area on the replication master, then an unpriv user rsyncs that tree to a holding area on the slave where an integrity check could be done. If it checks out OK, then the root user could rsync from there to the actual tree. Of course this process doesn't need to be applied to the whole tree, only the truly important parts, and it does make me wonder if you need rsyncing since you could dump the tree as "tar -czf - this/tree | ssh unprivuser@slave 'cat > tree.tgz'"... OK. Stop digressing. What you got:
- Replication master: access to host, priv keys. If this is a server without unpriv user shell access (except for trusted admin purposes) then you basically only got basic host hardening, public services and their vulnerabilities to worry about as intrusion vector. Make sure the keys have the least access privileges (and are chattr'ed if you can) and guarded by a file integrity check (Aide, Samhain or alike). If you had an LSM framework in place like SELinux or GRsecurity's RBAC, you could also control which processes are allowed access to they keys. If you think you don't need strict security on the host that may seem a bit overkill tho and it does rely on proper host hardening, else it's not effective.
- Replication slaves: access to host, ops using key. Apart from the same above, plus the "usual suspects" like firewalling and using tcp wrappers, you could set up restrictions like for instance the key can only be used from certain hosts and/or with a specific set of commands. Maybe read Using Rsync and SSH (keys, validating, and automation) or just "man sshd" start at /options field.


Well, that's all I can come up with. HTH.

Oops you're right.

Well i think i understood about half of what you said. To elaborate more on my setup, both the server and mirror are using a RHEL clone. Each machine has been patched with the latest kernal release, and each is system has been updated using the up2date feature.

The ssh package im using is openssh 3.9 for RHEL4.4
The firewall and SELinux are enabled.
Both machines are behind a separate linux gateway that acts as a firewall and a nat. Obviously port forwarding has been setup on the gateway to send port 22 traffic to the appropriate lan ip.

Basically I just want to rest easy at night knowing that by giving the server's root user private key access to remote mirrors, that I haven't opened the door for other people to log in and hack the remote machines. Again, passwordauthentication is turned off, so really the only way to ssh into one of the remote machines is by using the private key generated on the server. At least that's what I've been lead to believe.