Just adding the user backups
to the user group sudo
does not automatically give the account access to all files on the system. It gives the user the permission to run the sudo
command.
Since you are using public key authentication (presumably without a passphrase), I would approach this with security and ease of implementation in mind. Using ssh
allows you to restrict the user to execute only very specific commands. In this case, you can allow the user backups
to execute rsync
with superuser permissions.
You have already performed the key exchange and verified authentication is successful. In the authorized_keys
file on the remote host that you are backing the /home
directory from, you can add a command=
directive to the key that is used by the user backups
. This directive will only allow that command to be run when that key is used for authentication. So the first field of the key would look similar to this:
command="/path/to/sudo /path/to/rsync -az /home /local/folder" ssh-rsa AAAAB3NzaC1yblahblahblah
You can go even further and add more options to the key, such as from=myhost,no-pty,no-X11-forwarding
.
This should give you decent security and not require you to modify the underlying file system permissions. You will probably need to play with the command that you place in the authorized_keys
file until it works like you expect; it may take a bit to wrap your brain around it. The command specified in the authorized_keys
will basically override the rsync
options you will pass from the connecting host.
Lots of good information in man sshd
. You want to specifically read the AUTHORIZED_KEYS FORMAT section.
There are 2 parts to this question. First, why is there a difference between "Number of files" and "Number of files transferred". This is explained in the rsync manpage:
Number of files: is the count of all "files" (in the generic sense), which includes directories, symlinks, etc.
Number of files transferred: is the count of normal files that were updated via rsync’s delta-transfer algorithm, which does not include created dirs, symlinks, etc.
The difference here should be equal to the total amount of directories, symnlinks, other special files. Those were not "transferred" but just re-created.
Now for the second part, why is there a size difference with du. du shows the amount of disk space used by a file, not the size of the file. The same file can take up a different amount of disk space, if for example the filesystems blocksizes differ.
If you are still worried about data integrity, a easy way to be sure is to created hashes for all your files and compare:
( cd /home/hholtmann && find . -type f -exec md5sum {} \; ) > /tmp/hholtmann.md5sum
( cd /media/wd750/c51/home/ && md5sum -c /tmp/hholtmann.md5sum )
Best Answer
I would recommend that you just use the root account in the first place. If you set it up like this:
sshd_config
on the target machine toPermitRootLogin without-password
.ssh-keygen
on the machine that pulls the backup to create an SSH private key (only if you don't already have an SSH key). Do not set a passphrase. Google a tutorial if you need details for this, there should be plenty./root/.ssh/id_rsa.pub
of the backup machine to the/root/.ssh/authorized_keys
of your target machine.then the resulting setup should be pretty safe.
sudo
, especially combined withNOPASSWD
as recommended in the comments, has no security benefits over just using the root account. For example this suggestion:essentially gives
rsyncuser
root permissions anyway. You ask:Well, simple. With the recommended configuration,
rsyncuser
may now runrsync
as root without even being asked for a password.rsync
is a very powerful tool to manipulate files, so nowrsyncuser
has a very powerful tool to manipulate files with root permissions. Finding a way to exploit this took me just a few minutes (tested on Ubuntu 13.04, requiresdash
,bash
didn't work):As you can see, I have created myself a root shell;
whoami
identifies my account as root, I can create files in/etc
, and I can read from/etc/shadow
. My exploit was to set the setuid bit on thedash
binary; it causes Linux to always run that binary with the permissions of the owner, in this case root.No, clumsily working around the root account in situations where it is absolutely appropriate to use it is not for good reasons. This is just another form of cargo cult programming - you don't really understand the concept behind sudo vs root, you just blindly apply the belief "root is bad, sudo is good" because you've read that somewhere.
On the one hand, there are situations where
sudo
is definitely the right tool for the job. For example, when you're interactively working on a graphical Linux desktop, let's say Ubuntu, then having to usesudo
is fine in those rare cases where you sometimes need root access. Ubuntu intentionally has a disabled root account and forces you to usesudo
by default to prevent users from just always using the root account to log in. When the user just wants to use e.g. the web browser, then logging in as root would be a dangerous thing, and therefore not having a root account by default prevents stupid people from doing this.On the other hand, there are situations like yours, where an automated script requires root permissions to something, for example to make a backup. Now using
sudo
to work around the root account is not only pointless, it's also dangerous: at first glancersyncuser
looks like an ordinary unprivileged account. But as I've already explained, it would be very easy for an attacker to gain full root access if he had already gainedrsyncuser
access. So essentially, you now have an additional root account that doesn't look like a root account at all, which is not a good thing.