rsnapshot:
This article explains how to do system backups of Linux systems without leaving root ssh access open.
First, download rsnapshot from rsnapshot.org.
Use ssh-keygen to create public key (id_rsa.pub) as the backup user on the rsnapshot server.
Scp to /backupuser/.ssh/authorized_keys2 on the remote system to be backed up.
The backups only connect to do a “pull” of data from each remote system to the host server.
rsnapshot.conf configuration:
rsync_long_args -ev --rsync-path=/usr/bin/rsync-wrapper.sh
ssh_args -i /home/backupuser/.ssh/id_rsa
# Add a line for each remote system to back up:
backup backupuser@systemname:/. systemname/
See ‘man rsnapshot’ for info, or http://www.rsnapshot.org
Deploying rsnapshot:
* Create user on each system:
/usr/sbin/useradd backupuser -c "limited backup user" -m -u 10000 # pick a unique id across all systems
* Create ssh public key with customized access rules on backup server as the backup user. Change first line: from="ipaddress", command=" " ssh-rsa...
* Scp the public key (or authorized_keys2) from backup server to clients at /home/backupuser/.ssh
* Add limited sudo rights for backup user to rsync
* Copy rsync-wrapper.sh to each system under /usr/bin (included via cfengine)
#!/bin/sh
/usr/bin/sudo /usr/bin/rsync "$@";
* Optional: use ‘validate-rsync.sh’ script and copy to backupuser’s home on each system. Add to “command=” line in ssh key.
* Configure each backup line in rsnapshot.conf to run the backup as the backupuser
* Check your configuration: sudo rsnapshot configtest will check /etc/rsnapshot.conf for syntax
* To “initialize” the key, you may need to run this manually once from the backup server:
sudo ssh -i /home/backupuser/.ssh/id_rsa backupuser@servername
using a nonstandard port:
For servers with ssh on a nonstandard port, create this ssh config file with options for a particular server: /home/bkupuser/.ssh/config. (In this case, the file needs to be created under root’s .ssh folder, even though it will be run as a backup user)
Host servername
User bkupuser
Port 2222
HostName servername.edu
Debian difference:
Copy public key as “authorized_keys” (not authorized_keys2) and add fully qualified domain name to the end of the ssh key.
Useful Links that may help:
[Using Rsync and SSH|http://troy.jdmz.net/rsync/#ref2]
[Remote Filesystem Snapshots with rsnapshot|http://blog.innerewut.de/2005/06/03/follow-up-on-remote-filesystem-snapshots-with-rsnapshot]
[Remote rsnapshot backups with non-root user|http://osdir.com/ml/sysutils.backup.rsnapshot.general/2005-11/msg00047.html]
Pingback: How to use rsnapshot without remote root?
Hello, after using a really more complicated solution, I’ve read your article and use this solution with success.
Then, I’ve decided to detail your solution in a tutorial http://dev.kprod.net/?q=linux-backup-rsnapshot-no-root
I hope that’s ok for you (of course you are quoted at the end)
Thanks !
what’s the point in avoiding root ssh, if you now have a diffrent ssh user that’s powerful enough to rsync a new shadow file back in the other direction and gain a root shell ?
Good question.
– Creating a non-standard user for backups eliminates the most frequently guessed user login.
– You will of course want to lock down several things.
1. Limit the commands the user can run in the start of the ssh key (command=”/path/backupscript.sh” ssh-dss…). The backup user should only be able to run the backup script, and no other commands. They should be logged out if they don’t run the one specific command.
2. Limit who can ssh by IP address, perhaps using the firewall, /etc/hosts.allow, and/or fail2ban
3. Consider to only run this on your internal/backup network, avoiding any public access.
– …. .- -. -.- …