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.