I need to backup files with preserved attributes from a source workstation to a LAN server (both on Linux Mint, the server is running sshd and Samba). One of the solutions which preserves files' source attributes is to run rsync over ssh, something like that on the client side:

rsync -a --rsync-path="sudo rsync" -e ssh /media/user1/source user2@server:/media/user2/destination/

However for this to work as expected, rsync needs to be added to the sudoer list as NOPASSWD on the server side:

user2 ALL=NOPASSWD:/usr/bin/rsync

This setup makes backing up with attribute preservation work fine. But how secure it is to have a passwordless rsync on the server? Is it inviting problems? Or I'm thinking too much? Our main security concern is unauthorised copying of sensitive data by a motivated hacker. Clearly if you can sudo rsync you can send any file from the server to an arbitrary internet location.

What are your thoughts? If it's that bad, any suggestions on a LAN backup which would preserve attributes from the source on the LAN workstation?


3 Answers 3


As you may be aware, that line in /etc/sudoers allows user2 to run any arbitrary rsync command as root. This could be used to read or write any system file, including your password hashes and modifying the sudoers configuration to grant more access. rsync alone could even be used to run commands as root.

So it becomes clear that user2 can easily become root and do anything to the system. Your attack surface increases greatly when considering that user2's account is accessed remotely from other systems. If another system is compromised, an attacker could easily pivot to your backup server and become root. Not great on a backup server, that's for sure.

Probably the best thing you could do in the current scenario is to limit the sudo command further. If you are running the same rsync every time, you could probably hardcode the entire server-side rsync command, arguments and all, in the sudoers file. This way, sudo is only useful for doing the backups. You may need to do a little investigating to see exactly which command is being run on the server side.

Or, if user2 is only used for backups, you could make a custom rsync validation script for allowed commands and force it to be called using command= in user2's ~/.ssh/authorized_keys file, but filtering like this is difficult to make airtight sometimes.

Alternatively, the TAR format can be used to preserve attributes, and there are a number of solutions out there to do networked TAR backups.

  • Is this an example of the best thing you are suggesting: user2 ALL=(ALL) NOPASSWD:/usr/bin/rsync --server -vlogDtpre.iLsfxC . /media/user2/destination? If so, can this be exploited as well?
    – afora377
    Commented Jul 29, 2020 at 5:30
  • also does it matter that much if in this scenario user2 allowed to login to the server or not? I read somewhere recommending to disable user2 password, and I'm not clear on this. Just trying to understand a few basics here. Tu.
    – afora377
    Commented Jul 29, 2020 at 5:33
  • As long as that rsync command is the same every time, then it is fine. The only thing the attacker is able to do as root is run that above command. So depending on your setup, they could possibly overwrite your backups. Ideally you'd disable password login over SSH. Whether or not you need a password on the account itself likely only matters if you need to log in to that user from the console. Commented Jul 29, 2020 at 11:30
  • Actually, I just realized there may be another problem. If you are preserving file permissions, that means setuid files may have their permissions preserved. An attacker could rsync a file that is setuid root to your backup directory, and execute it to become root. I've not tested this but I'm assuming rsync preserves that as well. Commented Jul 29, 2020 at 11:33
  • Thank you for your thoughts! Feels like it's the end of the road then? Not possible to accomplish this without keeping the system secure?
    – afora377
    Commented Jul 31, 2020 at 0:27

The only safe and feasible solution that I found over time consists of:

  1. Generate a new ssh key specifically for passwordless backups only. Do not use a passphrase with it;

  2. Upload it to the server as your normal ssh user. Do not create another user for it, or upload it as www-data as www-data must not be able to login to the system;

  3. Change that uploaded key in authorized_keys to run a bash script rather than provide the user with a terminal on ssh login. An example would be to replace

    ssh-rsa AAAAB3Nza......k1y0=

    with something like this

    command="script.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3Nza......k1y0=
  4. In script.sh, you would have something like this:

      if [[ "$SSH_ORIGINAL_COMMAND" == "rsync --server --sender -vlDtre.iLsfxCIvu /home/server/files ." ]] 

    where "rsync --server --sender -vlDtre.iLsfxCIvu /home/server/files ." is an ssh digest you get from your server when you try to unsuccessfully login with

    rsync -av -e "ssh -i rsync_key" user@$ /home/user

    Upon this unsuccessful login, the value of the digest (i.e. its string value) will be recorded in $SSH_ORIGINAL_COMMAND;

  5. Things to consider: if you are backing up any webroot files which the standard ssh user does not have access to without sudo, add that user to group www-data

  6. Things to consider: www-data user will need to have maximally restrictive configuration. Ideally we would want something like this:


    which is achievable by running

      sudo usermod -d /nonexistent $wwwuser -s /usr/sbin/nologin
  7. Now you can ssh to the server to run a passwordless rsync backup

    rsync -av -e "ssh -i rsync_key" user@$ /home/user

It is advisable to use public-key security to protect the account. See:


Ignore all answers that recommend no password.

You are not running the user account with a password-less login. In fact I would disable password login. You are enabling this particular user to run rsync as root without a prompt for the root password. You may even be able to further restrict the user account to only run rsync. With public-key login, no password login, the threat is significantly reduced.

  • Just checking if I was referring to the same thing - I already use public key security to ssh from the client to the server. This was not the issue. The issue was having a rsync run on the server-side as a root. Im not sure that link is relevant? Or I may be wrong...
    – afora377
    Commented Jul 28, 2020 at 2:43
  • Running apps as root is a security risk. Running rsync, which is widely deployed, ages old, highly vetted, and just a foundation stone of Unix, is "probably fine". But not without public-key encryption if running password-less. Commented Jul 28, 2020 at 3:18
  • I did learn that using the rsync daemon with modules, which makes life so much easier, basically uses no passwords. You want the "-e ssh" option. Commented Jul 28, 2020 at 3:25
  • @afora377 You should (be able to) disable password login from the user account to tighten the security (significantly). It should be public-key accessible only. DuckDuckGo is your friend here. Commented Jul 28, 2020 at 3:29
  • @afora377 Be sure to research all the rsync options to ensure you are backing all needed permissions, ACL's, user ownership/group ownership, extended attributes, sparse-ness, creation/modification dates, etc. And then test thoroughly. I created a directory of test cases. In my case, I had to go from macOS to FreeBSD with different versions of rsync, and I lose some features. Commented Jul 28, 2020 at 3:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .