I am supporting a site that allows members to upload release files. I
have inherited this site which was previously existing. The goal is
to allow members to file transfer to and from their project area for
release distribution but not to allow general shell access and not to
allow access to other parts of the system.
Currently rsync and old scp has been restricted using a restricted
shell configuration. But of course that does not limit sftp. And of
course sftp can be chrooted which would work okay for us. Use the
ForceCommand internal-sftp configuration to put the process in a
chroot. But then that configuration blocks rsync.
Match ... other stuff
Match ALL
ChrootDirectory /releases
ForceCommand internal-sftp
AllowTcpForwarding no
X11Forwarding no
I have not been able to deduce a way to set up sftp-in-a-chroot *only*
when sftp is requested and allow rsync when rsync is requested and
allow rsync to work normally when rsync is requested.
Is there a way to allow rsync, scp and sftp but restrict the user to
only upload and download from specific directories? Something like if
the user is invoking sftp then chroot sftp but if the user is invoking
rsync then invoke the custom restricted shell.
I hate to have to tell everyone that we can only securely allow one of
either rsync or sftp but not both. But at this point I think it must
be one or the other and either-or seems not possible.
Thanks!
Bob
On Sat, 11 Nov 2023, Bob Proulx wrote:> I am supporting a site that allows members to upload release files. I > have inherited this site which was previously existing. The goal is > to allow members to file transfer to and from their project area for > release distribution but not to allow general shell access and not to > allow access to other parts of the system. > > Currently rsync and old scp has been restricted using a restricted > shell configuration. But of course that does not limit sftp. And of > course sftp can be chrooted which would work okay for us. Use the > ForceCommand internal-sftp configuration to put the process in a > chroot. But then that configuration blocks rsync. > > Match ... other stuff > Match ALL > ChrootDirectory /releases > ForceCommand internal-sftp > AllowTcpForwarding no > X11Forwarding no > > I have not been able to deduce a way to set up sftp-in-a-chroot *only* > when sftp is requested and allow rsync when rsync is requested and > allow rsync to work normally when rsync is requested.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. 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. If you're on Linux, then maybe you could cook something up using namespaces and bind mounts to simplify this. -d
On Sat, Nov 11, 2023 at 7:16?PM Bob Proulx <bob at proulx.com> wrote:> > I am supporting a site that allows members to upload release files. I > have inherited this site which was previously existing. The goal is > to allow members to file transfer to and from their project area for > release distribution but not to allow general shell access and not to > allow access to other parts of the system.The simplest answer is "don't bother". Switch to FTPS, which is supported with quite simple tools like vsftpd and is vastly simpler to entirely segregate user spaces for. If you have a compelling need to support scp and/or rsync, you can look at the old "rssh" tools, I used to publish RHEL wrappers for that at https://github.com/nkadel/rssh-chroot-tools , but stopped maintaining my copy years ago. They're far more burdensome, and maintaining the SFTP based "only see the upload or download folder" configs is a lot more work, than simply using vsftpd and FTPS.
On 12.11.23 01:08, Bob Proulx wrote:> Currently rsync and old scp has been restricted using a restricted > shell configuration. But of course that does not limit sftp. And of > course sftp can be chrooted which [...] blocks rsync.[...]> I hate to have to tell everyone that we can only securely allow one of > either rsync or sftp but not both. But at this point I think it must > be one or the other and either-or seems not possible.Call me cheap, but I'd try having the sshd listen on a second port and put the chroot+sftp config into a "Match LocalPort ..." block. Yes, that means the users cannot use a single .ssh/config entry for all the access modes, but considering that the chroot will change the apparently-absolute pathes for SFTP, anyway ... Kind regards, -- Jochen Bern Systemingenieur Binect GmbH -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3449 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20231113/626ebe9c/attachment-0001.p7s>