10

I'm trying to set up a backup server. I want to chroot each user (client) to its home directory, and only allow it to use sftp and rsync.

I quickly discovered that I was not the only one trying to do something like this, and I found this guide and followed it. So now I've got chroot'd users with sftp only.

Then I found out that rsync needs ssh to spawn itself on the other machine, and that sftp is not enough. Giving each user an ssh login is something that I wanted to avoid in the first place.

Can anyone think of some possible solutions?

Thank you,

Mark

11

An sftp solution would also require an ssh login for everyone, so you haven't really lost anything here. Granting ssh access does not necessarily imply full shell access, for example, this shows how to use the ssh authorized_keys file to allow backup via rsync while limiting available commands to just the rsync receiver.

In fact, if you opt for key based authentication, rather than password authentication (which you should), you could then run everything under one user account instead of requiring multiple accounts. You would use keys to identify remote users, and direct the rsync receiver at a particular directory.

Something like this, in your authorized_keys file:

command="/usr/bin/rsync --server -a . /tmp/user1" ssh-rsa ... user1
command="/usr/bin/rsync --server -a . /tmp/user2" ssh-rsa ... user2

Someone using the user1 private key will backup into /tmp/user1, and someone using the user2 private key will backup into /tmp/user2. And so forth...

  • Link is gone 404. – luckydonald Mar 28 at 23:14
  • I've updated the link. – larsks Mar 28 at 23:59
6

Execute usual rsync from client to remote server, but add additional verbose switch: SSH -v, then grep for Sending command. You will see exact command client is sending to remote server:

rsync -avz -e'ssh -v -i /ssh-keys/clientprivate.key' --bwlimit=8000 --delete root@server:/path/ /backup/myserver/ 2>&1 | grep "Sending command"

In my case, it was

rsync --server -vvlogDtprze.iLsf --bwlimit=8000 --delete . /path

Add this as command="..." to remote server /home/USER/.ssh/authorized_keys file as @larsks mentioned. Add aditional security settings, if necessary:

no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAAAB3NzaC1yc2..CPhIJ+LVULWz arnis@server

All together:

command="rsync --server -vvlogDtprze.iLsf --bwlimit=8000 --delete . /backup/path",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAAAB3NzaC1yc2..CPhIJ+LVULWz arnis@server

(Taken from very good tutorial http://en.positon.org/post/Rsync-command-restriction-over-SSH)

  • Good 1st answer. – slm Jan 1 '13 at 17:29
2

You are going to need to provide some form of shell access to be able to use rsync unless you are connecting directly to the rsync server - default port is 873 (TCP).

From the rysnc man page:

There are two different ways for rsync to contact a remote system: using a remote-shell program as the transport (such as ssh or rsh) or contacting an rsync daemon directly via TCP. The remote-shell transport is used whenever the source or destination path contains a single colon (:) separator after a host specification. Contacting an rsync daemon directly happens when the source or destination path contains a double colon (::) separator after a host specification, OR when an rsync:// URL is specified (see also the lqUSING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTIONrq section for an exception to this latter rule).

To provide limited shell access, consider the following guide. (Note: the original link is dead) Summary:

This setup combines the best features from rsync, SSH, and chroot. Rsync provides the flexibility and efficiency in files transfer, SSH protects the data being transferred, and chroot protects data on the server from unauthorized access. The dummysh limits the access to rsync only.

While rsync server implements chroot, it lacks the SSH protection that is often required. Besides, opening an additional rsync server port presents a security risk and sometimes is not possible either technically or politically. Sftp and scp lack the flexibility and efficiency provided by rsync, especially when a directory tree is involved, such as a Web site.

Or take a look at using rssh (there is a guide to setting up rssh here):

rssh is a restricted shell for use with OpenSSH, allowing only scp and/or sftp. It now also includes support for rdist, rsync, and cvs. For example, if you have a server which you only want to allow users to copy files off of via scp, without providing shell access, you can use rssh to do that.

0

you can write a shell that wraps rsync.

look at the general idea here: https://sixohthree.com/1458/locking-down-rsync-using-ssh

in your wrapping shell you can do what you want and maybe chroot the user.

In my case I needed to switch on virtual account using the same *nix user. I manage to do so using this kind of shell plus many lines in the authorized_keys file. I have not chrooted the user but I've added a user folder level in the rsync server command.

look at process user differently using ssh key

0

SFTP with Rsync capabilities, without a shell

You can use LFTP+SFTP in a chroot environment and achieve the same results as using rsync, without providing the user a shell or doing any heavy customizations in ssh with wrappers.

This is more secure and can be substantially faster.

0

Rsync into chroot is tricky :) You'll need to setup minimal environment for /bin/sh and /usr/bin/rsync within the chrooted directory (destination-side) in order for it to work.

See the whole article here, the rsync-environment setup is by the end
https://medium.com/@deltazero/linux-remote-backup-rsync-chroot-d797ba6babe5

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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