Description of problem:

scponly prevents rsync from working.

Message presented to client:

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

Message logged on server:

Sep  5 09:04:28 dtn01 scponly[30450]: option 'e' or a related long option is not permitted for use with /bin/rsync (arg was .Ls) (username: joan5896(416810), IP/port: 10.225.160.12 40708 22))
Sep  5 09:04:28 dtn01 scponly[30450]: requested command (/bin/rsync --server -e.Ls .) tried to use disallowed argument (username: joan5896(416810), IP/port: 10.225.160.12 40708 22))

Appears to be fixed upstream, but outside of any release.

https://github.com/scponly/scponly/commit/346c69075558b9360ba872386b194ead621df856


Version-Release number of selected component (if applicable):

scponly-4.8-18.el7.x86_64

Workaround of specifying `--protocol=29` from the rsync client appears effective for now.


How reproducible:

Always


Steps to Reproduce:
1. Configure user with /usr/bin/scponly as shell
2. Attempt to rsync as user from step 1 with default arguments

Actual results:

Transfer fails


Expected results:

Transfer succeeds


Additional info:

Please let us know if we should be moving on to a different package. scponly is a nice fit for us and we use sssd to override all domain users to it on specific data-transfer servers, but if there's a newer best-practice we'd be happy to do that.