Ryfujk

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

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...

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)

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.

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

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.