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' 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 Nov 4 '15 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 Nov 4 '15 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 Nov 5 '15 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. – Mark Plotnick Nov 5 '15 at 20:17

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.


I know it's an old post, but just in case it can help other people...

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.).


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? – roaima Sep 9 '16 at 9:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.