I do not have a root password for many of the servers I interact with so I can not SSH directly in as the root user. Also, the ssh daemons are wisely configured with ‘PermitRootLogin’ set to ‘no’ so a password would be moot anyway. I do have sudo permissions on the servers so I can connect under my username and sudo the privileged commands as needed. Glazed-eye screen-staring started when I needed to rsync a remote directory that was read-only for root. How do I get rsync to run under sudo on the remote server? I did some searching and here are some options I found.
Option 1. Set NOPASSWD in the /etc/sudoers file.
Then use the --rsync-path option to specify the sudo wrapper.
Option 2. For interactive usage, I can pre-activate sudo and then run rsync as in Option 1.
The “stty -echo” and “stty echo” is used to temporarily disable the display of the keyboard input to prevent the sudo password from being displayed.
Credits: Wayne Davison and Julian Cowley
Option 3. If sudo is not available, there is possibly an option to use “su”. I was unable to get this to work. su seems to insist on a tty – I get the error ‘standard in must be a tty’. (In this case I do have a root password to use with su, so that’s not an issue).
Create a wrapper script, /usr/local/bin/su-rsync, on the remote server and make it executable.
su – -c "rsync $*"
Then call that script with the --rsync-path option.
Credit: Wayne Davison
Option 4. Set ‘PermitRootLogin’ to ‘yes’ on the remote server and use SSH key authentication to login directly as the root user. This isn’t really an option for me but I throw it out there for sake of completeness.
crashingdaily 
42 comments
Comments feed for this article
September 10, 2008 at 7:40 am
Xavier Martinez-Hidalgo
Note that, in Option 2, you can use the ssh -t switch:
ssh -t server.remotehost.com sudo -v
to force ssh to allocate a pseudo-tty and avoid the need of using the “stty -echo” and “stty echo” commands.
September 11, 2008 at 3:58 am
crashingdaily
Hi Xavier, I am able to
ssh -t server.remotehost.com “sudo -v”
and then
ssh -t server.remotehost.com “sudo ls /root”
but the sudo rsync doesn’t work for me unless I add “Defaults !tty_tickets” to /etc/sudoers.
Still, this is a great suggestion for my other remote sudo needs. Thank you!
March 4, 2009 at 6:25 am
Josiah Purtlebaugh
I found this article very helpful; thank you.
April 6, 2009 at 8:58 pm
Sam
Very helpful, thank you.
May 12, 2010 at 9:13 am
Steph
It helped me thanks a lot
May 13, 2010 at 8:17 pm
Gerry
> Option 1. Set NOPASSWD in the /etc/sudoers file.
> crashingdaily ALL= NOPASSWD:/usr/bin/rsync
Ummm so then the account is able to use sudo rsync to edit the /etc/sudoers file making this pointless.
August 31, 2010 at 2:24 pm
Olli
Thanks, this article was really helpful.
November 5, 2010 at 9:18 pm
Mike
thanks, this fixed the perms ownership issue i had.. :)
November 5, 2010 at 11:18 pm
Gerry
@Olli
@Mike
If you give the user sudo permissions on rsync then they can just rsync over the sudoers file as I’ve pointed out above. Right? What am I missing here?
November 6, 2010 at 3:08 am
crashingdaily
Hi Gerry, yes I could use rsync to edit the sudoers file but I typically use visudo for that.
November 6, 2010 at 3:15 pm
Gerry
My point is, that if rsync is able to modify the very file that restricts root access to only rsync, then the restriction is pointless and you may as well realise you are giving full root access to the server. Which means anybody who has sudo access or access to the crashingdaily user on the first server will then be able to get full root access (not limited to rsync) on the server.remotehost.com server.
November 6, 2010 at 4:03 pm
crashingdaily
Right, Gerry, but I already have full root access through sudo, not restricted only to rsync. The specific rsync entry in sudoers in Option 1 is to remove the password requirement as a convenience (with some increase in exploitation risk, sure, so may not be appropriate for all environments).
Your point is a very important consideration for others who stumble across this posting and may be thinking about implementing this for an untrusted user. You are right, it should not be done in those cases.
March 4, 2011 at 11:21 am
marco
great, thanks
April 7, 2011 at 11:03 am
Running Rsync and Sudo over SSH | TechniTip.Net
[…] Rsync and sudo over SSH Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages. Related posts:socket: Address family not supported by protocol […]
June 21, 2011 at 11:46 am
helifreak
(1) In my hands, if the rsync command in Option 2 is not run as sudo, file ownerships are not preserved (source is the remote machine, and destination is the local machine). Am I missing something?
(2) I’m curious about exactly what the “stty -echo …” command of Option 2 accomplishes. On my machine (Ubuntu 10.04) “ssh server.remotehost.com sudo -v” alone produces a password prompt, and typing in a (dummy) passward echoes nothing. Running both of Option 2’s commands (the second as sudo) generates three password prompts, none of which are echoed. Are any of these password entries going out as clear text?
July 1, 2011 at 2:16 pm
crashingdaily
@helifreak, (1). That sounds accurate. You need root privileges to change (or preserve) file ownerships.
(2). I was using RHEL 4 when I wrote this blog posting. On that system sudo would prompt for a password even if there was no tty. When there was no tty the password characters would echo. The newer versions of sudo default to requiring a tty.
On my RHEL 5 systems, I can reproduce the behavior you describe by adding
to /etc/sudoers and using a pseudotty (ssh -t). I’m prompted for a password but the characters are not echoed to my local terminal.
I can restore the old behavior of character echo by adding in /etc/sudoers
The passwords are not going out as clear text.
July 31, 2011 at 9:23 am
Backup via rsync « netzdings.de
[…] https://crashingdaily.wordpress.com/2007/06/29/rsync-and-sudo-over-ssh/ […]
August 24, 2011 at 8:48 am
Fabien
I have an existential question: what if create a sudoers file of my own that says:
crashingdaily ALL= (ALL) NOPASSWD:ALL
Then I push it to /etc using the freshly granted “sudo rsync”?
September 26, 2011 at 9:40 pm
Emanuel Greisen
Why do you not just restrict the rsync command by enforcing some arguments:
crashindaily ALL=NOPASSWD:/usr/bin/rsync –server * /backup/directory/*
This will allow you to make backup to subdirectories of “/backup/directory” but it will not make it possible to overwrite the sudoers file.
September 27, 2011 at 1:42 pm
Emanuel Greisen
Please disregard my lame suggestion, as you can just do:
rsync /evil_etc/ poorhost:/backup/directory/../../etc
April 9, 2012 at 10:04 pm
helifreak
Scripts put together as described above that continue to work fine on Ubuntu 10.04 boxes do not work when adpated for a Ubuntu 11.10 System76 laptop. Digging around in some developer sites revealed that the default settings for sudo have been changed so that sudo status is now applied on a “per tty” basis, which means, I think, that this trick:
stty -echo; ssh server.remotehost.com sudo -v; stty echo
no longer passes on sudo status to subsequent rsyncing commands. The solution is to add the flag !tty_tickets to /etc/sudoers via visudo. So /etc/sudoers needs these two lines:
Defaults visiblepw
Defaults !tty_tickets
That’s the ticket!
July 31, 2012 at 2:05 pm
stummi
There is a little mistake in the text. If you want to give positional parameter 1-to-1 through scripts, you shuoldn’t use $* but “$@” instead (with quotes)
August 10, 2012 at 5:37 am
rsync with sudo (CentOS 5) | blog.sampls.org
[…] sudo + rsync | きぬろぐ rsync and sudo over SSH « crashingdaily sudoが「sudo: sorry, you must have a tty to run […]
September 21, 2012 at 8:45 am
GG
Hi all,
Emanuel Greisen had the idea but I see no one still pointed out the working set.
I’ll reply to those pointing out that giving rsync sudo powers is dangerous/pointless as rsync can edit everything included sudoers that is limiting users’ power:
-> if you need rsync w/ perms or root access there is no other way I know of, BUT:
–> you can secure things using openssh.
so I use authorized_keys for passwordless login.
using rsync -e “ssh -v” –params /source user@host:/dest
you get the command issued on the server.
copy the string and add
from=”ip/fqdn”,command=”sudo rsync bla bla (output of -v at some point)” ssh-rsa key blabla
in the authorized keys.
In my way of understanding this the only command allowed is the one here specified. So it is the server allowind rsync to only access some paths
Not a step-by-step-detailed comment but hopefully sharing something usefull.
Please inform if you see any vulnerability. I am using this in production and would be greatful to any enhancement
Cheers,
GG
October 16, 2012 at 8:29 am
Per Olesen
Thanks man, didn’t know about “–rsync-path”. Got here, because ssh stopped setting PATH (I think stopped reading std login shell environment) as it used too even though it wasn’t a login shell..
August 14, 2013 at 3:34 pm
William Pietri
Thanks! Exactly what I needed when I was trying to figure out how to do a backup-and-restore quality rsync via ssh.
October 5, 2013 at 9:28 pm
Damian Nowak
Option 2 does not work for me.
# stty -echo; ssh user@example.com ‘sudo -v’; stty echo
user@example.com‘s password:
sudo: no tty present and no askpass program specified
Even if I perform sudo -v manually after ssh user@example.com, rsync complains.
# rsync -a -e ssh –rsync-path=”sudo rsync” user@example.com:/etc/http-proxy/ssl/ ssl/
user@example.com‘s password:
sudo: no tty present and no askpass program specified
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
May 12, 2014 at 9:14 pm
Dan
Used in conjunction with this project/package:
http://sourceforge.net/projects/pamsshagentauth/ (pam_ssh_agent_auth)
… You can up the security a bit by using ssh agent forwarding and public key authentication. With this method, you only have to enter the password for your private key once OR leave the private key password blank the file unreadable by others for automatic scripts.
I this page useful in my automatic rsync from “root to root” searches and wanted to make sure there was a connection to the above project.
April 22, 2015 at 4:20 pm
Mike
What is/was the solution for using root on the destination machine?
In my environment we can’t allow the sshd_config to allow root login, via PermitRootLogin = yes
To get around that we setup ssh keys without pass passphrases, add those keys to a user on the destination server, set entries in sudo to allow the secondary user to sudo to root to execute rsync in order that the correct permissions, etc. are set on the destination server.
In reviewing the discussions above, I don’t see that my method is any more secure that PermitRootLogin = yes, it just passes the security scan inspection for sshd_config.
Has anyone come up with a better solution?
April 22, 2015 at 6:22 pm
Fabien
I have in mind using SElinux to grant to a regular user access on specific folders. Has anyone tested it already?
April 22, 2015 at 6:40 pm
crashingdaily
Are you allowing sudo to a root shell or sudo to run a specific rsync command?
These are my opinions on some of many options:
User ssh -> sudo -> restricted command : The best option to limit liability. Restricting to selected files/directories may require a custom wrapper script on rsync to prevent the ‘../..’ bypass that Emanual noted in his comment.
User ssh+password (PasswordAuthentication yes) -> sudo+password -> root shell : A malicious user can brute-force the user password, use that to sudo a root shell. Only slightly more effort than brute forcing root’s password with ‘PermitRootLogin yes’ enabled. It does provide some logging of which user invoked sudo and when.
User ssh+key (PasswordAuthentication no) -> sudo+password -> root shell : A malicious user would need shell access before brute forcing the sudo password. If the user shell requires a key (password auth is disabled) then this is better than ‘PermitRootLogin yes’. This also provides some logging of which user invoked sudo and when.
Root ssh+password (PermitRootLogin yes) -> root shell : The password can be brute-forced remotely. Dangerous.
Root ssh+key (PermitRootLogin without-password) -> root shell : hard to brute force the key. It still leaves root shell accessible through any security flaws in sshd that bypass the auth mechanism.
April 23, 2015 at 4:20 pm
Mike
Crashingdaily,
I am using ssh into a regular user on the remote system, that then is set up in sudoers to execute the rsync command. However, as was pointed out previously, a user could wipe out the /etc/shadow if they wanted to, so maybe adding rsync commands with only specified directories in suoders would be safest, but maybe tha is overskill too.
sudoers file:
rsyncuser hostname=NOPASSWD: /usr/local/bin/rsync
On Source System:
/usr/local/bin/rsync -avHD –delete -e “ssh -l rsyncuser -x” \
–rsync-path=”/usr/local/bin/sudo /usr/local/bin/rsync” \
/var/spool/cron/crontabs/ destination_host:/var/backup/crontabs/
May 19, 2015 at 3:00 am
» Linux/How To: Backing Up Your Data
[…] disable the need for the password when rsync is used, or send the password to the server. The crashingdaily blog has a good discussion of […]
August 12, 2015 at 7:19 am
SupportSages – Web Hosting Support | Data transfer using Rsync without root access
[…] https://crashingdaily.wordpress.com/2007/06/29/rsync-and-sudo-over-ssh/ […]
April 24, 2016 at 3:37 pm
Backing Up Your Data – Cyber Tech
[…] disable the need for the password when rsync is used, or send the password to the server. The crashingdaily blog has a good discussion of […]
June 5, 2016 at 4:04 pm
rsync and sudo over SSH | crashingdaily – Human-Error Processor
[…] Source: rsync and sudo over SSH | crashingdaily […]
December 7, 2016 at 2:45 pm
Brian Johnson
Excellent post, thank you!
December 14, 2016 at 4:29 pm
Pull files from a remote server over ssh with sudo privilege escalation – NathanFriend.co.uk
[…] Original source: https://crashingdaily.wordpress.com/2007/06/29/rsync-and-sudo-over-ssh/ […]
January 19, 2017 at 5:55 pm
Kaolin Fire
Beautiful, thanks! Great way to snarf things out of tmp as a backup in case the machine reboots when experimenting….
June 3, 2017 at 10:47 am
Compra socialmedia aqui
Tienes twitter?
January 3, 2018 at 9:44 am
delt
Thanks, helps a lot to sync files between servers!
In my /etc/profile.d/aliases.sh (my file where i keep all my aliases, this gets run automatically by bash in ubuntu, mint, debian, etc etc) i added the following:
if [ “$UID” = “0” ]; then
alias rsync=’sudo -u user rsync –rsync-path=”sudo rsync”‘
fi
– Replace “user” by your (non-root) username.
– Remote user must have permission to use ‘sudo’.
– Can’t rsync files which ‘user’ can’t read :(
What this does is, if you are root (ie. UID is zero) then it creates the alias to run rsync as another user on the local system, but tells the remote system to run rsync as root. … now you can just type rsync as you would normally =)
The only (big) downside is that since your normal user account may not have read access to certain files, ie. SSL certificates, and so on, then you can’t rsync those (for now… im working on it :D
September 19, 2018 at 8:58 pm
rsync and sudo over SSH | crashingdaily | Human-Error Processor
[…] Source: rsync and sudo over SSH | crashingdaily […]