Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am configuring a backup server using Dirvish which will backup several Ubuntu servers over the Internet.

As part of our security policy, we don't allow ssh logins as root on our servers.

How can I use Dirvish to backup my servers, without logging in as root, and without providing the dirvish user with NOPASSWORD in sudoers?

The ideal solution should involve minimum configuration on the backed-up, target machines.

share|improve this question
up vote 3 down vote accepted

For anyone looking here's the solution I went with.

Key points:

  1. Dirvish doesn't support running rsync via sudo (Why, I do not know)

  2. In AUTHORIZED_KEYS you can restrict the conditions under which a key is authorized, including specifying a single permitted command, and a single source IP address.

In sshd_config you can specify that ssh root login is only permitted when the -command flag is specified and the command matches the one in AUTHORIZED_KEYS

PermitRootLogin forced-commands-only

A full procedure is here:

share|improve this answer
You could also restrict the root SSH login to only your dirvish server, see – Andrew Aug 19 '11 at 4:13

You are on the right track with not allowing root logins via SSH. However your prerequisite about sudo is unreasonable.

However, sudo allows very fine grained control over exactly what can and cannot be executed by a given user. You can allow the dirvish user to ONLY execute exactly one binary without a password.

Combine this with key-based authentication for that user, and you have yourself a backup solution.

share|improve this answer
Hi, thanks for your reply. The problem is that dirvish uses rsync on the target machine. Rsync could be abused to either, grab a backup of the whole machine, or write anything you want to it (eg: /etc/shadow or /etc/sudoers. So limiting dirvish to only rsync isn't really ideal. – Rich Apr 13 '11 at 0:34
@Rich you are quite right about rsync having enough actiosn built into the binary that giving away sudo access to it gives away the system. However your solution is no different, it just moves the attack surface from one machine to another. You still gave away root access to rsync, but instead of being able to compromise box X from X, you can only do it from Y. – Caleb Apr 13 '11 at 7:31
I fully agree with your reasoning. I only went with the solution I did because it works well with Dirvish, which doesn't support offer any way to rsync via Sudo. – Rich Apr 14 '11 at 0:13

I am adding a second answer with a different solution in light of more details of the problem coming out. Apparently dirvish uses rsync on the backend, and @Rich is quite right to point out that allowing sudo access even just to that one command gives full control over the root file system.

In light of this, I would suggest some work with user groups such that the user dirvish runs as has read access to the files needing to be backed up by virtue of being in the right user group. This way you can avoid having any root level vulnerabilities.

share|improve this answer
Hi Caleb. Once again thanks for taking the time to answer. Your suggestion is a good one; but in this case I want to do full server backups. – Rich Apr 14 '11 at 0:15
In that case the only way to not increase your attack surface by giving the backup machine full control over your host is to initiate the backup from the host and push the backup files instead of pull them. – Caleb Apr 14 '11 at 7:20

Would using the sshd flag "PermitRootLogin without-password" be an option? Then you could only login with the corresponding public key. For more security you could enable a second ssh server on another port and allow keyauth only there.

share|improve this answer
This is a really bad idea. Enabling root logins, even key based and even on another port is NOT recommended. Think about what happens if the backup server get's compromised! Much better to fine tune what can and cannot be done so that even if the backup server is compromised, it doesn't have root permissions on another box, just ability to read/backup files. – Caleb Apr 12 '11 at 14:08
caleb, i think you misunderstand the option ;) The option means, that root is not allowed to login via password, but is allowed to login with public-key! – shakalandy Apr 12 '11 at 14:12
I understand the option and I understand public-key authentication. The problem is that any script logging into any system and getting root permissions on the destination leaves significant attack surface. – Caleb Apr 12 '11 at 14:15
if your connection is incoming from a static ip your firewall should be able to handle the rest of the "significant attack surface". – shakalandy Apr 12 '11 at 14:20
the attack surface I am referring to is not the ability to login to the box ... there are lots of ways to limit that and public key authentication is generally effective at this. The problem is that some machine somewhere (the backup server) has the key and is logging in, presumably automated, and is being granted too many privileges on the destination system. A backup script shouldn't have root privileges on a target system. No amount of iptables magic will mitigate an attack coming from a trusted system! – Caleb Apr 12 '11 at 14:25

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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