rsync with different user

Question

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

Solution 1

You have to differentiate 2 things:

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

Overview

(srcmachine)  (rsync)   (destmachine)
  srcuser    -- SSH -->   destuser
                             |
                             | sudo su jenkins
                             |
                             v
                          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.

Solution

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

Explanations

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

Requirements

SSH access

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

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

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
destuser ALL=(ALL) NOPASSWD:ALL
EOF

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

sudo su jenkins
echo $USER

If it returns:

jenkins

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
[~/.ssh/id_rsa.pub]

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

Solution 2

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.

Solution 3

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.

Comments

[Admin]

Did you added the ssh-key on the remote hosts authorized_keys file or on the server where you are running the rsync command?

[Admin]

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.

[Admin]

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?

[Admin]

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.

[roaima]

If the rsync is failed due to an authentication issue how will your suggestion help?

[Adam Barnes]

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.