# scponly and rsync



## Mormegil (Oct 10, 2009)

I'm trying to implement backups using rsync and scponly, but they don't seem to be working well together.  Rsync to a regular user works fine, sftp and scp to scponly work fine, but I can't rsync to the scponly user.  I have rsync set up on both machines, and a test user with the following user data on the remote machine.


```
bacman:*:1002:1002:User &:/home/backups:/usr/local/sbin/scponlyc
```

All the software is installed via an up to date ports tree, and scponly was indeed installed with rsync support.  I'm aware of alternatives I could use to do this but I want to know why specifically this isn't working.  I've spent the past few hours (not sleeping and) trying to figure out why this is failing.  There doesn't seem to be very much discussion on this kind of setup, and the only real lead I found refers to a bug that was fixed several years ago.

Trying to use rsync to push data to the remote machine fails as follows:


```
roy@eressea:roy$ rsync -ave ssh --delete --numeric-ids testdata bacman@beleriand:/home/backups/incoming

You shall not pass

Password:
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]
```

The following error message appears in auth.log on the remote machine


```
Oct 10 16:28:47 beleriand scponly[86939]: option 'e' or a related long option is not permitted for use with /usr/local/bin/rsync (arg was .iL) 
(username: bacman(1002), IP/port: xxx.xxx.xxx.xxx 63172 22))
Oct 10 16:28:47 beleriand scponly[86939]: requested command (/usr/local/bin/rsync --server -vlogDtpre.iL --delete --numeric-ids . /home/backups
/incoming) tried to use disallowed argument (username: bacman(1002), IP/port: xxx.xxx.xxx.xxx 63172 22))
```

Thanks for any insight into this.


----------



## DutchDaemon (Oct 10, 2009)

I'm pretty sure you can only rsync to a user with a 'regular' shell on the other end (i.e. (ba|c|tc|z|k)sh, not /usr/local/sbin/scponlyc), which allows the rsync process to be called on the other end and establishes a connection between the two rsync processes. The scponlyc 'shell' has purposefully limited functionality, likely obstructing access to rsync at the other end. Note that while ssh is used as the 'transport layer', a call from rsync to the other rsync is made over that transport layer to produce the actual synchronisation of data. That call fails. The ssh transport layer is probably doing just fine 

So either create an rsync user with a working shell (might as well use sysutils/rsnapshot), or try rsync*d* as a service (rsyncd.conf(5)).


----------



## Mormegil (Oct 11, 2009)

Thanks for the info, the documentation and discussion on this seems pretty sparse and I guess I've been looking at this the wrong way.  I've used rsnapshot, it's a great solution. I was just playing with this to get my hands dirty and got really obsessed over why it wouldn't work.


----------



## Mormegil (Oct 11, 2009)

After digging through the scponly mailing list archives, I'm not actually sure whether this is the case.

http://lists.ccs.neu.edu/pipermail/scponly/2008-October/001985.html

This seems like the exact same problem I'm having, and the rsync and scponly versions are still the same as they were a year ago when the thread was started.  I'm going to deinstall the scponly port and see whether installing via CVS helps at all.


----------



## Mormegil (Oct 11, 2009)

This rush of endorphins is what makes all the agony worth it.

Mark this topic as solved and note that rsync support is broken with the scponly port.  To get it to work, I downloaded the development snapshot as described at the scponly wiki, then


```
# ./configure --prefix=/usr/local/scponly --enable-rsync-compat --enable-chrooted-binary && make && make install
# make jail
# for i in /usr/local/scponly/{bin,etc,sbin}/* ; do ln -s $i /usr/local/`echo $i | awk -F/ '{print $5}'` ; done (because I felt like it :P)
# echo 'OPTIONAL_MANPATH      /usr/local/scponly/man' >> /etc/manpath.conf
```

I did a test with the same rsync command as in my OP and it works.


----------



## many68 (Mar 17, 2010)

*Try downgrade rsync*

I have been doing remote backups this way for a while. Several servers backed up their data by sending it to another machine. The machine receiving the data has scponly installed with chroot. A different user with a different chrooted environment was used for every backed up server.

This worked great until I upgraded the rsync on the sending machines to version 3. If I downgrade rsync on the sending machines to rsync 2.x, eventhough I still have the latest rsync + the latest scponly on the receiving machine, it works.

I tried to reinstall rsync 3.x on the sending machines with diffeerent build options. I couldn't get it t work!

You can downgrade the port with the "portdowngrade" port. Then add rsync to the  /usr/local/etc/pkgtools.conf file to prevent it from being upgraded again the next time you do a portupgrade -a.


----------



## rfarmer (Dec 7, 2010)

Large bump (sorry!) but somebody just sent this to me and I have patched the port so rsync 3.x should work now.

http://lists.freebsd.org/pipermail/cvs-ports/2010-December/207991.html


----------

