我之前也遇到过类似的备份权限与安全平衡的问题，给你几个经过实践验证的方案，你可以根据自己的环境选择：

方案一：限制root SSH密钥的执行范围（推荐，最小改动） #

这个方法不用创建新用户，也完全不会影响root的正常shell访问，核心是通过SSH的authorized_keys配置，让备份服务器的SSH密钥只能执行指定的rsync命令，彻底禁止交互式shell登录。

具体步骤：

1. 在源服务器的/root/.ssh/authorized_keys文件中，找到备份服务器的公钥行，在最前面添加限制参数：

   command="rsync --server --sender -logDtprze.iLsfx --numeric-ids . /home",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD...
   

   • command=后面的内容是rsync客户端发起请求时会触发的服务器端命令（你可以先手动执行一次rsync备份，从源服务器的日志里拿到准确的server端命令，替换进去更稳妥）
   • 后面的no-*选项彻底禁用了端口转发、X11转发等风险功能，确保这个密钥只能用来同步文件

优势：

• 不需要额外创建用户，直接利用root权限读取所有/home文件
• 完全不影响root的正常shell登录（其他密钥或密码登录不受限）
• 即使备份服务器被攻陷，攻击者拿到这个密钥也只能执行指定的rsync命令，无法获得交互式shell

方案二：专用备份用户+sudo+Chroot SFTP（更安全的隔离） #

如果不想用root密钥，这个方案通过创建一个专用的备份用户，结合sudo获取root权限，同时把用户Chroot在SFTP环境里，彻底隔离风险。

步骤：

1. 创建备份用户（比如backupuser），禁止其shell登录：

   useradd -m -s /usr/sbin/nologin backupuser
   

2. 配置sshd，让backupuser只能通过Chroot SFTP访问：
   在/etc/ssh/sshd_config中添加或修改：

   Match User backupuser
       ForceCommand internal-sftp
       ChrootDirectory /home/backupuser
       PermitTunnel no
       AllowAgentForwarding no
       AllowTcpForwarding no
       X11Forwarding no
   

   然后重启sshd：systemctl restart sshd
3. 给backupuser配置sudo权限，允许其免密执行rsync命令：
   编辑sudoers文件（用visudo避免语法错误），添加：

   backupuser ALL=(ALL) NOPASSWD: /usr/bin/rsync
   

4. 执行备份时，用--rsync-path指定sudo rsync：

   rsync -avz --rsync-path="sudo rsync" backupuser@source-server:/home/ /backup/destination/
   

优势：

• 专用用户隔离，即使密钥泄露，攻击者只能操作这个受限用户
• Chroot环境进一步限制了用户的访问范围
• 通过sudo获取root权限，能读取所有/home文件，同时保留原文件权限

方案三：rsnapshot整合受限密钥配置 #

如果你用rsnapshot，其实可以直接在rsnapshot的配置文件里指定受限的SSH参数，把密钥的限制逻辑整合到自动化备份流程中：
在/etc/rsnapshot.conf中添加：

backup  root@source-server:/home/  backup/  +ssh_args="-i /path/to/limited-key -o Command='rsync --server --sender ...'"

本质和方案一类似，只是把密钥限制参数直接写入备份配置，更适合自动化场景。

备注：内容来源于stack exchange，提问作者ropchain