Mike Leone via plug on 28 Mar 2025 05:38:16 -0700


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Problems chrooting for sftp on RedHat




On Thu, Mar 27, 2025 at 6:10 PM brent saner via plug <plug@lists.phillylinux.org> wrote:
On Thu, Mar 27, 2025 at 2:54 PM Mike Leone via plug <plug@lists.phillylinux.org> wrote:
I'm having a problem on a Red Hat cluster. We want the users to be able to only sftp in, and only to their own home directory. Pretty standard.

So here's the setup. We have a folder structure /sftp-area/vendor/<user>. All users are a member of a group called "FileCollector". Here's what it looks like:
<snipped out other directories>

SO first off, you mention `/sftp-area/` here. Below shows `/ftp-area`. Typo?

Yes, sorry. I'm assisting on this project.
 
 [root@PHAFTP002 /]# ls -la
total 36
drwxrwxrwx.   5 root FileCollector 4096 Jul 26  2022 ftp-area

Nope. make this 0755 or 0555, owned root:root. See sshd_config(5), `ChrootDirectory` description, first paragraph.
 
[root@PHAFTP002 ftp-area]# ls -la
total 28
drwxrwxrwx.  5 root FileCollector  4096 Jul 26  2022 .
dr-xr-xr-x. 21 root root            278 Mar 27 09:14 ..
drwx------.  2 root root          16384 Jul 25  2022 lost+found
drwxr-x--x.  6 root root           4096 Jul 25  2022 nfsinfo
drwxrwxr-x. 10 root FileCollector  4096 Mar 27 10:53 vendor
[root@PHAFTP002 ftp-area]#

Nope. `vendor` should be 0755 or 0555, root:root. (0751 or 0711 or 0551 or  0511 should work fine as well, from recollection.)
 
[root@PHAFTP002 vendor]# ls -la
total 40
drwxrwxr-x. 10 root     FileCollector 4096 Mar 27 10:53 .
drwxrwxrwx.  5 root     FileCollector 4096 Jul 26  2022 ..
drwxrwxr-x.  4 lowespro FileCollector 4096 Mar 27 11:19 lowespro

OK, so the user "lowespro" has a home directory of /ftp-area/vendor/lowespro.

[root@PHAFTP002 vendor]# cat /etc/passwd
lowespro:x:1009:1001::/ftp-area/vendor/lowespro/home:/bin/bash
[root@PHAFTP002 vendor]#

Nope. ChrootDirectory is set (per below) as /ftp-area/vendor/%u

This is a root. When user `foo` logs in, their `/` will be mapped to `/ftp-area/vendor/foo` ACTUAL.

Thus a user with a homedir of `/ftp-area/vendor/lowespro/home` is actually mapped to real path `/ftp-area/vendor/lowespro/ftp-area/vendor/lowespro/home` for homedir.

You probably don't want that.

No. We want it to map to '/ftp-area/vendior/lowespro' (I assume).
 
Yep. ChrootDirectory section in sshd_config(5), first paragraph for perms/ownership on all leading paths, and the homedirs for the users is probably not what you want it to be.

Based on what seems to be your desired behavior:

  1. find /ftp-area/vendor -mindepth 2 -maxdepth 2 -type d -name 'home' -exec chmod 0750 '{}' \;
  2. chmod 0551 /ftp-area{,/vendor}
  3. chown root:root /ftp-area{,/vendor{,/*}}
  4. chmod 0555 /ftp-area/vendor/*
  5. /etc/ssh/sshd_config: ChrootDirectory /ftp-area/vendor/%u
  6. restart sshd
  7. change home directory for ALL sftp-chrooted users to `/home`
should let you do what you want without changing any hierarchy.

That won't let members of `FileCollector` see or access other "chrooted homes", though. That's not going to be possible with a tokenized ChrootDirectory.
What you'd want to do INSTEAD in THAT case is (in ADDITION to steps 2, 3, 4 above):

  1. set the homedir to the nice clean system default for the chrooted sftp users to `/home/<username>` (i.e. /home/<vendor>)
  2. mkdir /ftp-area/vendor/home
  3. chown root:root /ftp-area/vendor/home
  4. chmod 0751 /ftp-area/vendor/home
  5. (make a dir for every vendor as /ftp-area/vendor/home/<vendor>)
  6. (chown <vendor>:FileCollector /ftp-area/vendor/home/<vendor>)
  7. find /ftp-area/vendor/home -mindepth 1 -maxdepth 1 -type d -exec chmod 0750 '{}' \;
  8. /etc/ssh/sshd_config: ChrootDirectory /ftp-area/vendor
  9. restart sshd
that will let any sftp-chrooted user, as long as they're in FileCollector, *access* other vendor dirs (e.g. the sftp command `cd /home/<other_vendor>/some_sub_directory` will work) but NOT list them (e.g. sftp command `ls /home` will NOT WORK).
I CANNOT stress this enough, though, that security through obscurity is not security at all, and if you need to grant cross-vendor access this should really be done with POSIX ACLs[0] instead, and selectively so.

We don't need to grant that, no.

Thanks, I'll forward this to my colleague and we'll see what happens. 
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug


--

Mike. Leone, <mailto:turgon@mike-leone.com>

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: <http://www.flickr.com/photos/mikeleonephotos>

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug