Cfrtjryk

I have this command to backup a remote machine. The problem is that I need root rights to read and copy all files. I have no root user enabled for security reasons and use sudo the Ubuntu way. Would I need some cool piping or something to do this?

rsync -chavzP --stats user@192.168.1.2:/ /media/backupdisk/myserverbackup/

I would recommend that you just use the root account in the first place. If you set it up like this:

• Configure your sshd_config on the target machine to PermitRootLogin without-password.


• Use ssh-keygen on the machine that pulls the backup to create an SSH private key (only if you don't already have an SSH key). Do not set a passphrase. Google a tutorial if you need details for this, there should be plenty.


• Append the contents of /root/.ssh/id_rsa.pub of the backup machine to the /root/.ssh/authorized_keys of your target machine.


• Now your backup machine has root access to your target machine, without having to use password authentication.

then the resulting setup should be pretty safe.

sudo, especially combined with NOPASSWD as recommended in the comments, has no security benefits over just using the root account. For example this suggestion:

add the following to your /etc/sudoers file: rsyncuser ALL= NOPASSWD:/usr/bin/rsync

essentially gives rsyncuser root permissions anyway. You ask:

@MartinvonWittich Easy to gain a full root shell because rsync executed with sudo? Walk [m]e [through] that please.

Well, simple. With the recommended configuration, rsyncuser may now run rsync as root without even being asked for a password. rsync is a very powerful tool to manipulate files, so now rsyncuser has a very powerful tool to manipulate files with root permissions. Finding a way to exploit this took me just a few minutes (tested on Ubuntu 13.04, requires dash, bash didn't work):

martin@martin ~ % sudo rsync --perms --chmod u+s /bin/dash /bin/rootdash

martin@martin ~ % rootdash

# whoami

root

# touch /etc/evil

# tail -n1 /etc/shadow

dnsmasq:*:15942:0:99999:7:::

As you can see, I have created myself a root shell; whoami identifies my account as root, I can create files in /etc, and I can read from /etc/shadow. My exploit was to set the setuid bit on the dash binary; it causes Linux to always run that binary with the permissions of the owner, in this case root.

Having a real root is not [recommended] for good reasons. – redanimalwar 15 hours ago

No, clumsily working around the root account in situations where it is absolutely appropriate to use it is not for good reasons. This is just another form of cargo cult programming - you don't really understand the concept behind sudo vs root, you just blindly apply the belief "root is bad, sudo is good" because you've read that somewhere.

On the one hand, there are situations where sudo is definitely the right tool for the job. For example, when you're interactively working on a graphical Linux desktop, let's say Ubuntu, then having to use sudo is fine in those rare cases where you sometimes need root access. Ubuntu intentionally has a disabled root account and forces you to use sudo by default to prevent users from just always using the root account to log in. When the user just wants to use e.g. the web browser, then logging in as root would be a dangerous thing, and therefore not having a root account by default prevents stupid people from doing this.

On the other hand, there are situations like yours, where an automated script requires root permissions to something, for example to make a backup. Now using sudo to work around the root account is not only pointless, it's also dangerous: at first glance rsyncuser looks like an ordinary unprivileged account. But as I've already explained, it would be very easy for an attacker to gain full root access if he had already gained rsyncuser access. So essentially, you now have an additional root account that doesn't look like a root account at all, which is not a good thing.

Make use of the --rsync-path option to make the remote rsync command run with sudo privileges. Your command should then be e.g.:

rsync -chavzP --rsync-path="sudo rsync" --stats user@192.168.1.2:/ .

If sudo prompts you for a password, you have to avoid that either by using a NOPASSWD privilege with the remote user account (pointless for root, may make sense in other use cases), or if you don't want to do that:

• 
  

  Make sure that the option tty_tickets is disabled for the user you
  are using, by running e.g. sudo visudo -f /etc/sudoers.d/local-rsync
  and entering:

  
  
  

  Defaults:your.username.for.rsync !tty_tickets
  
  

  
  



• Make sure that the option requiretty is disabled for the user you are
  using - it could be off by default. The method is the same as above.




• Seed the sudo password on the remote machine, by running e.g.
  ssh -t user@192.168.1.2 sudo

One simple way to do this is to use the graphical ssh-askpass program with sudo, this gets around the fact that sudo is not connected to the terminal and allows you to enter the password safely:

rsync -chavzPe 'ssh -X' --stats 

  --rsync-path='SUDO_ASKPASS=/usr/lib/ssh/x11-ssh-askpass sudo -A rsync' 

  user@192.168.1.2:/ .

Of course the ssh-askpass program must be installed in the given location and you must be running an X session on the machine you are working on. There are a few variations on the ssh-askpass program which should also work (Gnome/KDE versions). Also a graphical sudo replacement program like gksu or kdesudo should also work.

If your user has already sudo privileges which are protected with a password I would keep them as-is and only add a stanza to use rsync without a password:

%admin ALL=(ALL) ALL

%admin ALL= NOPASSWD:/usr/bin/rsync