28

I want to sync a folder from my machine with a folder on a remote machine. The remote folder can only be manipulated by root. I have an account on the remote machine which can use sudo. How can I run rsync such that it has root permissions on the remote machine?

I've tried the following:

rsync -avz -e ssh /home/ubuntu/my/lovely/folder ubuntu@x.x.x.x:/remote/lovely/folder --delete --rsync-path="sudo rsync"

But (after entering my password) I get the following error:

sudo: no tty present and no askpass program specified
|improve this question
  • Can you not change the permissions on the remote folder so that your user has write access to it? – Phil Apr 14 '11 at 19:34
  • 1
    Unfortunately that isn't an option. – Peter Apr 15 '11 at 8:11
  • It's much better to check the answer on the same question on Unix SE unix.stackexchange.com/questions/92123/…. – ndemou Jan 17 '17 at 16:51
11

This is the solution I came up with:

rsync -R -avz -e ssh --rsync-path="echo mypassword | sudo -S  mkdir -p /remote/lovely/folder && sudo rsync" /home/ubuntu/my/lovely/folder ubuntu@x.x.x.x:/remote/lovely/folder --delete

Bit of a mission!

|improve this answer
  • 9
    I hope you recognize your password will be visible in the command line. It should be visible for the length of time the rsync is running. – BillThor Apr 16 '11 at 2:02
  • 1
    where is the password visible? Just on the local box in the command line? Or does this approach create remote vulnerabilities too? I'm trying to understand the answer above and the ramifications of using this solution. I asked a question here: superuser.com/questions/398146/… – MountainX Mar 7 '12 at 21:15
  • @MountainX It'll be visible in list of processes (e.g. ps aux). Test: rsync -R -avz -e ssh --rsync-path="find / > /dev/null && rsync" server.example.com:/ /tmp/example, then open terminal on remote machine and ps aux | grep find. find / is used only as it's the first thing that came to my mind with large execution duration. – Ivan Vučica May 17 '14 at 19:05
  • @IvanVučica thanks for the good explanation – MountainX May 17 '14 at 23:42
  • 1
    I know this is old but, If you want to avoid the password in the command you can use key's for ssh and on the remote machine add your user to the sudoers file with the NOPASSWD: ALL flag. See the highest rank answer at the following link. NOTE: It's not the accepted answer: askubuntu.com/questions/147241/execute-sudo-without-password – Dave Dec 15 '15 at 9:16
10

The solution on this blog worked really well for me: http://www.pplux.com/2009/02/07/rsync-root-and-sudo/.

Basically:

stty -echo; ssh myUser@REMOTE_SERVER "sudo -v"; stty echo  
rsync -avze ssh --rsync-path='sudo rsync' myUser@REMOTE_SERVER:/REMOTE_PATH/ LOCAL_PATH

The first line allows for interactive password entry, without showing the password on the screen. Works great for me on Ubuntu 9.04.

|improve this answer
  • 1
    This requires the tty_tickets option to be unset: !tty_tickets. – blueyed Dec 19 '11 at 13:12
  • 2
    How about ssh -t [other options] instead of playing with stty -echo? – Ivan Vučica May 17 '14 at 19:10
  • I my case I have already unset: tty_tickets anyway... so I may try this approach. – MountainX May 17 '14 at 23:43
  • 1
    sudo: no tty present and no askpass program specified – Michael Apr 15 '16 at 3:08
  • How does one unset tty_tickets? On which machine? During this rsync command? – Jonathan Aug 26 '16 at 20:54
9

Try this solution. In your sudoers file (/etc/sudoers) setup your user like this:

username ALL= NOPASSWD:/usr/bin/rsync

the NOPASSWD:/usr/bin/rsync tells sudo that when your user runs /usr/bin/rsync or just rsync that no password is needed.

Then your original --rsync-path="sudo rsync" should work.

|improve this answer
  • I used sudo rsync option without setting username ALL... after rsync done. on the remote when I try to cd or ls. I get permission denied. even though I'm root. i have to sudo to ls. but in case of cd it is even not possible. I tried to chown all directories and files. still didn't work. anybody know the reason and how to fix it? – Dreaded semicolon Jun 30 '15 at 18:14
  • 1
    you should also say how to edit the sudoers file – Jonathan Aug 26 '16 at 20:57
  • Please see unix.stackexchange.com/a/92397/128237 for security implications of this fix. – BrainStorm.exe Mar 6 '18 at 18:27
4

You need a method to supply the password to sudo. An askpass program is designed to ask for passwords when the normal mechanisms aren't available. Setting up sudo to not require a password to run rsync as your userid is one option.

I normally configure key based login with appropriate restrictions for cases like this. If you configure a restricted key that an only run rsync as root then this kind of thing gets easier to do. Another alternative is to use an rsycnd process to handle the remote requests. The configuration provides a variety of restrictions that can be applied.

EDIT: I included a script to setup keys for key based loings in the Creating Userids on Clients section of my post on Setting up BackupPC on Linux. See also the documenation for ssh_config which details some of the things you can do with resticting key usage as shown in the script.

|improve this answer
  • Thanks for your help, but I found a solution that works better for me. – Peter Apr 15 '11 at 15:20
  • any details about keybased login? – TheVillageIdiot May 9 '11 at 10:29
3

on remote machine

sudo apt install ssh-askpass
which ssh-askpass

then on local machine 

rsync -av -e 'ssh -X' --rsync-path='SUDO_ASKPASS=/usr/libexec/openssh/ssh-askpass sudo -A rsync' /some/local/path user@remote:/some/remote/path

substitute path to ssh-askpass with actual path on remote machine

source: http://unix.bris.ac.uk/2015/08/04/rsync-between-two-hosts-using-sudo-and-a-password-prompt/

|improve this answer
1

I'm amazed by the complexity of the existing answers. It's far easier and convenient to configure your systems (your PC and the remote host) so that you can connect as root to the remote host without using a password. And unlike the looks of it it's secure too.

  1. On the remote host make sure that /etc/ssh/sshd_config has this line "PermitRootLogin without-password" (in many distributions it's there by default). This allows root to get an ssh shell using any authentication method except the insecure password prompt.
  2. (If you don't already know how) follow any of the many tutorials on how to obtain passwordless login via ssh
  3. Use rsync as you would normally do and without any password prompts.

Just don't forget that as long as the line in /root/.ssh/authorized_keys of the remote host is there that machine accepts root commands from your PC.

|improve this answer
0

Here is what worked for me, considering that I want to keep password authentication (so I don't want to use NOPASSWD or keys) - on Ubuntu 14.04:

  • "Open up" sudo on remote machine by disabling tty_tickets through a temporary file in /etc/sudoers.d/ (which should be supported on Debian, see /etc/sudoers.d/README), and "Update the user's cached credentials", which "extends the sudo timeout for another 15 minutes"
  • Run the rsync with sudo as shown in other answers
  • "Close down" sudo on remote machine by removing the temporary file in /etc/sudoers.d/, which re-enables tty_tickets

... or, with command lines:

ssh -t $REMOTEPC 'echo "Defaults !tty_tickets" | sudo tee /etc/sudoers.d/temp; sudo -v'
rsync -aP -e 'ssh' '--rsync-path=sudo rsync' /etc/pulse/client.conf $REMOTEPC:/etc/pulse/client-copy.conf
ssh -t $REMOTEPC 'sudo rm -v /etc/sudoers.d/temp; sudo -v'

These are the responses I get when running these commands on the local machine:

$ ssh -t $REMOTEPC 'echo "Defaults !tty_tickets" | sudo tee /etc/sudoers.d/temp; sudo -v'
remoteuser@$REMOTEPC's password: 
[sudo] password for remoteuser: 
Defaults !tty_tickets
Connection to $REMOTEPC closed.

$ rsync -aP -e 'ssh' '--rsync-path=sudo rsync' /etc/pulse/client.conf $REMOTEPC:/etc/pulse/client-copy.conf
remoteuser@$REMOTEPC's password: 
sending incremental file list
client.conf
           1269 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)

$ ssh -t $REMOTEPC 'sudo rm -v /etc/sudoers.d/temp; sudo -v'
remoteuser@$REMOTEPC's password: 
removed ‘/etc/sudoers.d/temp’
[sudo] password for remoteuser: 
Connection to $REMOTEPC closed.

Note that sudo -v should be ran after each time files in /etc/sudoers.d/, so the changes therein are accepted.

|improve this answer
0

Another method is to get around the permissions restrictions by initiating rsync on the remote machine. Instead of: 

rsync /home/ubuntu/my/lovely/folder ubuntu@x.x.x.x:/remote/lovely/folder

You can do: 

ssh ubuntu@x.x.x.x 'rsync ubuntu@y.y.y.y:/home/ubuntu/my/lovely/folder /remote/lovely/folder'

Where y.y.y.y is your local machine's IP address. This only works if your local machine can act as an SSH server.

|improve this answer
  • 1
    Hm... aren't you copying local to remote in your first command line - and then in the second command line, which should be equivalent to the first, copying remote to local (which isn't equivalent to the first)? – sdaau Dec 5 '17 at 11:39
  • Whoops! Fixed it. – Keith Dec 7 '17 at 2:51
0

My workuround is to add --rsync-path="echo PASSWORD | sudo -Sv && sudo rsync"

example:

rsync -avz -e ssh /home/ubuntu/my/lovely/folder ubuntu@x.x.x.x:/remote/lovely/folder --delete --rsync-path="echo <PASSWORD> | sudo -Sv && sudo rsync"

It usually isn't a good idea to put passwords into a command line one-liner; they become visible in the process tree, for example. I sometimes replace the actual password in this type of statement with $( cat my_password.txt ) which is slightly better

rsync -avz -e ssh /home/ubuntu/my/lovely/folder ubuntu@x.x.x.x:/remote/lovely/folder --delete --rsync-path="cat my_password.txt | sudo -Sv && sudo rsync"

|improve this answer
  • Can you expand on this with a little context and explanation? "add" to what, where? Why does this solve the problem? Thanks. – fixer1234 Aug 28 '18 at 8:37

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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