restrict file transfer in rsync, scp, sftp?

Bob Proulx bob at
Mon Nov 13 04:35:27 AEDT 2023

TL;DR: I'll jump down the rabbit hole of creating a ForceCommand which
does the chroot selection itself or not.  Thanks!

Damien Miller wrote:
> Bob Proulx wrote:
> >     Match ALL
> >         ChrootDirectory /releases
> >         ForceCommand internal-sftp
> ...
> You can do this using a custom setuid shell or forcecommand (it needs
> to be setuid because chroot requires privileges). It can look at
> the contents of $SSH_ORIGINAL_COMMAND and decide on whether to run
> rsync or chroot then run sftp-server.

The problem I hit with that idea is that then the chroot requires a
full chroot system setup rather than the internal-sftp which works
internally and does not require the full chroot environment.  The
shared libraries needed is not too much issue but the user accounts
are kept in an SQL datbase so wiring that it seemed messy.  That's the
reason I was trying to deduce a method to use "ForceCommand
internal-sftp" which works directly.

I have entertained the idea of splitting the host into two hosts.  One
would have an IP address for sftp and the other would have an IP
address for rsync and the two would not need to overlap.  That's a
possibility because the host size could be very small.  If this were a
*BSD system I would use a vnet jail.  This is a Linux system.  (Maybe
this will be the motivation for me to learn Linux containers.)

> It is possible to do this without setuid, but the forcecommand would
> need to live inside the ChrootDirectory along with everything else
> sftp-server and rsync needs.

The setuid requirement itself is not a problem.  The attraction of
internal-sftp is that it is already there and already self-contained.
The problem of needing the user account database in the chroot makes
doing it without internal-sftp to be messy.

Though maybe I have avoided it too quickly and should just work the
problem and see.  I am going to jump into this rabbit hole and see
what I find there.  Though I am torn between it and the brute force
idea of splitting the host into separate sftp and rsync dedicated
transfer ones.  But then people would need to be switched from one dns
name which I am sure they have coded to another that they would need
to learn.  I'll jump into the ForceCommand handler for a bit and see
what I learn by working that side of the problem.

> If you're on Linux, then maybe you could cook something up using
> namespaces and bind mounts to simplify this.

I neglected to say one more thing that figures into the problem.  The
storage space is on an NFS mount.  Which honestly has more benefits
than problems.  There are several hosts that share the storage space.
This does not prevent doing clever things.  But it can make things
more interesting.  If possible keeping things simple and plain is my


More information about the openssh-unix-dev mailing list