I'm working with two ubuntu instances on AWS (which I use a pem key to access them).

I set up rsync for both instances, and it works if I use the default user which is ubuntu@ipaddress. However if I try to use rsync with another user (I'm typing sudo su - jenkins for example or even typing sudo before the rsync command), then I get the following error.

Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: unexplained error (code 255) at io.c(226) [Receiver=3.1.0]

Steps that I've taken:

I've tried creating an ssh key (using ssh-keygen) while logged in as jenkins and added that to the authorized_keys file in both /home/ubuntu/.ssh/authorized_keys (where i'm running the rsync from) and even $JENKINS_HOME/.ssh/authorized_keys (where I tried running rsync from there too).

I even tried using the pem key to do the same thing and that didn't work either.

Here's what I'm trying to run

rsync -avuh --delete -e ssh jenkins@ipaddress:/var/lib/jenkins/* /var/lib/jenkins

And here's with the key file

rsync -avuh --delete -e 'ssh -i path/to/key.pem' [email protected]:/var/lib/jenkins/* /var/lib/jenkins

P.S.: The only reason why I don't want to run it with the ubuntu user is because I get failed: Permission denied (13) on a lot of things (since the files are owned by jenkins).

End goal:

I'm trying to keep the backup jenkins instance backed up constantly with the primary instance by doing a cronjob:

*/30 * * * * /usr/bin/rsync -avuh --delete -e ssh root@jenkinsprimary:/var/lib/jenkins/* /var/lib/jenkins

  • Did you added the ssh-key on the remote hosts authorized_keys file or on the server where you are running the rsync command?
    – AlphaBeta
    Commented Nov 4, 2015 at 18:31
  • 1
    The question isn't quite clear. In every rsync run you have a source and destination. Can you clarify the source and destination systems? For troubleshooting purposes, I recommend sticking with just ssh over rsync, because rsync will use ssh. Try using ssh -vvv jenkins@<target> from the source and pasting the output here.
    – Jesse K
    Commented Nov 4, 2015 at 19:06
  • I get failed: Permission denied (13) on a lot of things (since the files are owned by jenkins) So why not perform the rsync as the "jenkins" user?
    – wurtel
    Commented Nov 5, 2015 at 15:54
  • You wrote I've tried creating an ssh key (using ssh-keygen) while logged in as jenkins and added that to the authorized_keys file in both /home/ubuntu/.ssh/authorized_keys (where i'm running the rsync from), but you should be adding the key to the authorized_keys file on the destination system. Commented Nov 5, 2015 at 20:17

5 Answers 5


You have to differentiate 2 things:

  • who establishes the SSH connection.
  • which remote user owns the files that you want to copy.


(srcmachine)  (rsync)   (destmachine)
  srcuser    -- SSH -->   destuser
                             | sudo su jenkins

Let's say that you want to rsync:

  • From:
    • Machine: srcmachine
    • User: srcuser
    • Directory: /var/lib/jenkins
  • To:
    • Machine: destmachine
    • User: destuser to establish the SSH connection.
    • Directory: /tmp
    • Final files owner: jenkins.


rsync --rsync-path 'sudo -u jenkins rsync' -avP --delete /var/lib/jenkins destuser@destmachine:/tmp


     --rsync-path=PROGRAM    specify the rsync to run on the remote machine

The trick is to tell to run rsync on the remote machine with another user (jenkins) than the one who establishes the SSH connection (destuser).


SSH access

(srcmachine)         (rsync)   (destmachine)
  srcuser           -- SSH -->   destuser

[~/.ssh/id_rsa]                [~/.ssh/authorized_keys] <-- "id_rsa.pub" inside

Don't forget to restrict permissions on ~/.ssh:

chmod 700 ~/.ssh

sudoer for the destuser

The destuser must have the privilege to do sudo -u jenkins rsync.

In general, we set the destuser as a member of the sudoers. To do this, on the root@destmachine:

cat > /etc/sudoers.d/destuser << EOF

To test it before rsync, you can log onto the destuser@destmachine and run this:

sudo su jenkins
echo $USER

If it returns:


it means that you are logged as jenkins user, and it means that your rsync command will work as well, because the escalade privilege to jenkins works.

Note about a bad solution: establish the SSH connection with the destination user jenkins

Why don't we just do this?

(srcmachine)         (rsync)   (destmachine)
  srcuser           -- SSH -->    jenkins

[~/.ssh/id_rsa]                [~/.ssh/authorized_keys] <-- "id_rsa.pub" inside

because jenkins is a "service" account, which means that it runs a service which exposes a port (80 or so) for external HTTP access, and it means that it is POSSIBLE that there is a security breach through the Jenkins service over HTTP to gain access.

That's why we have www-data user and similars to run the different services. In case they get hacked from the ports they expose, they can't do much:

  • everything is read-only for them.
  • except writing in /var/log/THE_SERVICE.

So allowing SSH access for the jenkins user exposes a surface attack (and so it is for SSH access as root!!).

Moreover, if you want to rsync as another user (root, www-data, etc.), you would have to copy your SSH key public key to those accounts (troublesome).

Good solution: You should set SSH access as few as possible to user accounts (destuser) that CAN escaladate to the "service" account you want (jenkins, root, etc.).

  • It seems like an rsync-specific user would be the best solution, no? Or one per unrelated folder you want to rsync. That way, the rsync users can have authorised keys for all deploy agents, server administrators still have their own accounts, and unrelated users like www-data/jenkins aren't being used to write data they should only be reading. Commented Apr 22, 2022 at 15:48
  • I don't think you're achieving what you said you want to achieve with this method (reduce surface area). You're actually increasing surface area, because destuser, being in sudoer, has greater perms than jenkins.
    – John
    Commented Dec 1, 2022 at 15:54

I had a similar issue with rsyncing as another user. Solved it by running next command:

rsync -avu -e "ssh -i my-key -o StrictHostKeyChecking=no -l user-i-want-to-use-in-rsync" ./local_dir remote_host:remote-host-dir

Please note, that maybe you will need to play with keys to be able to run rsync as another user.

sudo -u jenkins -i rsync ...

with no quotes.

The -i option makes the sudo command run with the environment of the user including ssh keys, .profile, .bash_profile etc.

From the sudo man:

-i, --login

Run the shell specified by the target user's password database entry as a login shell. This means that login-specific resource files such as .profile, .bash_profile or .login will be read by the shell. If a command is specified, it is passed to the shell for execution via the shell's -c option. If no command is specified, an interactive shell is executed. sudo attempts to change to that user's home directory before running the shell. The command is run with an environment similar to the one a user would receive at log in. Note that most shells behave differently when a command is specified as compared to an interactive session; consult the shell's manual for details. The Command environment section in the sudoers(5) manual documents how the -i option affects the environment in which a command is run when the sudoers policy is in use.


May I suggest a slightly different approach ?

The answer from @samuelphan worked for me but was highly contorted in my situation. I decided on a simpler solution because the sync I wanted to do was temporary: fist I temporarily enabled root ssh login via key in /etc/ssh/sshd_config on line PermitRootLogin prohibit-password

Then I copied root's ssh public key to the destination /root/.ssh/authorized_keys and tested the connection via sudo ssh root@destination

Then I performed my sync: sudo rsync -avx /home root@destination:/tmp_home

And finally I disabled ssh root login


I have similar issue.
I solve this using cron. But cron must run with specific user (ex: jenkins)

Just make cron job:

$ crontab -u jenkins -e

then fill cron with your need.

*/2 * * * * sh /home/user/scp.sh 2>&1 >> /home/user/errmail.log
  • If the rsync is failed due to an authentication issue how will your suggestion help? Commented Sep 9, 2016 at 9:14

You must log in to answer this question.

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