I'm running OpenSSH_7.4p1 (CentOS7) and have been asked to build a sort of "drop box" to allow clients read-only access from a certain directory. Right now, I've implemented this with the following lines in /etc/ssh/sshd_config: Subsystem sftp internal-sftp Match User update_user ChrootDirectory /opt/dropbox ForceCommand internal-sftp -d / -R This is mostly working; it's allowing read-only access and restricting the connecting user to the /opt/dropbox directory. I am concerned about the following note in the man page: 'For file transfer sessions using ''sftp'', no additional configuration of the environment is necessary if the in-process sftp server is used, *though sessions which use logging do require **/dev/log inside the chroot directory'* As I haven't created a /dev/log socket in the directory, I am concerned that there is logging information I will wish I had. Looking at the -p and -P options, I wonder if there isn't a more fine-grained approach possible, to perhaps whitelist only the commands necessary for two operations: to list the contents of the current directory and retrieve the files. My attempts so far to restrict opendir, lstat, read, readdir, realpath, etc. haven't been successful. For example, restricting "opendir" gives an error that the client can't get the CWD and the session fails. Any pointers? -Cheers, Travis
On Thu, Sep 2, 2021 at 7:10 PM Travis Hayes <travis.hayes at gmail.com> wrote:> > I'm running OpenSSH_7.4p1 (CentOS7) and have been asked to build a sort of > "drop box" to allow clients read-only access from a certain directory.If you can't do it gracefully with SFTP, for whatever reason, consider sidestepping the issue and using FTPS with vsftpd. As much as I appreciate OpenSSH and SSH in general, restricted directory access has never been one of its most graceful uses. And vsftpd takes about 10 minutes to install and set up sanely.
On Thu, 2 Sep 2021, Travis Hayes wrote:> I'm running OpenSSH_7.4p1 (CentOS7) and have been asked to build a sort of > "drop box" to allow clients read-only access from a certain directory. > > Right now, I've implemented this with the following lines in > /etc/ssh/sshd_config: > > Subsystem sftp internal-sftp > Match User update_user > ChrootDirectory /opt/dropbox > ForceCommand internal-sftp -d / -R > > This is mostly working; it's allowing read-only access and restricting the > connecting user to the /opt/dropbox directory. I am concerned about the > following note in the man page: 'For file transfer sessions using ''sftp'', > no additional configuration of the environment is necessary if the > in-process sftp server is used, *though sessions which use logging do > require **/dev/log inside the chroot directory'* > > As I haven't created a /dev/log socket in the directory, I am concerned > that there is logging information I will wish I had.There's very little logged at the default loglevel, but most operations are logged at -lVERBOSE.> Looking at the -p and -P options, I wonder if there isn't a more > fine-grained approach possible, to perhaps whitelist only the commands > necessary for two operations: to list the contents of the current directory > and retrieve the files. My attempts so far to restrict opendir, lstat, > read, readdir, realpath, etc. haven't been successful. For example, > restricting "opendir" gives an error that the client can't get the CWD and > the session fails.Yes, most clients issue an FXP_OPENDIR to figure out their "home directory" since the protocol has no notion of one other than the current working directory the server starts at. For listing and downloading files, you'll need to allow something like: open,close,read,lstat,fstat,opendir,readdir,realpath,stat -d
On 03.09.21 01:05, Travis Hayes wrote:> I am concerned about the > following note in the man page: 'For file transfer sessions using ''sftp'', > no additional configuration of the environment is necessary if the > in-process sftp server is used, *though sessions which use logging do > require **/dev/log inside the chroot directory'* > > As I haven't created a /dev/log socket in the directory, I am concerned > that there is logging information I will wish I had.Note that providing a large number of chroots with /dev/log scales very poorly, because you'll need to configure your syslogd(-variant) to access and read every single one of them. On our SFTP server - which happens to be CentOS 7 as well -, I provide stub /etc/passwd and /etc/group (just so that directory listings will not show bare UIDs/GIDs), an empty /dev , a /README text file for a welcome(*), a writable subdir for the uploads, and told the sshd to (among other things): SyslogFacility AUTHPRIV Subsystem sftp internal-sftp Match group mandanten ForceCommand internal-sftp -l INFO -u 0077 Banner /home/chroot/README AuthorizedKeysCommand [...] (**) AuthorizedKeysCommandUser [...] - and nonetheless get to see all the open's and close's recorded in /var/log/secure . (*) Individual /READMEs get refreshed in regular intervals, by appending the respective user's current disk quota status to the global /home/chroot/README . I make a point of having a Banner right from square one so that automated clients will not enter production unless they've been taught to deal with the extra noise. (**) Using the AuthorizedKeysCommand system allows me to keep the management of pubkeys a) in our hands and b) out of the chroots. Both are our policy choices; YMMV. Regards, -- Jochen Bern Systemingenieur T +49 6151 9067-231 F +49 6151 9067-290 E jochen.bern at binect.de W www.binect.de Binect GmbH Robert-Koch-Str. 9 64331 Weiterstadt Gesch?ftspost.Einfach.Digital. Wir sind nach ISO/IEC 27001:2013 und 9001:2015 zertifiziert. BMWi f?rdert digitale L?sungen f?r KMU. Gesch?ftsf?hrung: Dr. Frank Wermeyer, Michael Imiolczyk Unternehmenssitz: Weiterstadt Register: Amtsgericht Darmstadt, HRB 94685 Umsatzsteuer-ID: DE 221 302 264 -------------- 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/20210903/a1a10aa6/attachment.p7s>