0

For some of my users, I need to allow them SFTP access to one or several directories. Multiple users can have access to the same directory. But for directories they don't have permission for, they can't see neither directories' names no can't browse them; What is the best (easiest & more secure) way to achieve my goal and to maintain future changes ?

I know there are those ways to do it : chroot, mount bind, ACL. I tried it (and also played with chown and chmod), but the users can still see and browse others directories via Filezilla.

Any help ?

My config :

All of my users (user1, user2 ...) are in the group "group_sftp_external_users".

Debian 10

My directories structure :

   /var/temp/all/dir_1
   /var/temp/all/dir_2
   /var/temp/all/dir_3
   /var/temp/all/dir_4
   /var/temp/all/dir_5

In "/etc/ssh/sshd_config" :

Match Group group_sftp_external_users
        ChrootDirectory /var/temp/all
        ForceCommand internal-sftp
        X11Forwarding no
        AllowTcpForwarding no
        AllowAgentForwarding no
        PermitTunnel no
        PubkeyAuthentication no
        PasswordAuthentication yes
        PermitEmptyPasswords no
FlipFlap
  • 1
  • 1
  • 2

1 Answers1

0

First be aware that such a setup would allow these users to pass ANY data (including KP, state secrets, stolen credit cards...) between each other. You're hosting an open relay between these users, and you might become legally liable for helping them should they decide to do something that your local government dislikes. At a bare minimum, you need to keep logs of their file activity, and review those logs.

Next, I'm going to STRONGLY recommend that you use chroot, as these are untrusted users. https://www.the-art-of-web.com/system/sftp-logging-chroot/ Does an excellent job of explaining how to do this, but my needs don't quite match that. My needs do roughly match what you are describing, however, so I think my solution can serve as a good starting point.

My strategy is to create a single chroot for all sftp users, and use file permissions to blind them to each other's homes. Specifically, my file structure looks like this:

  • /sftp_files 755 root.root <- mount point for drive with HPI

    • /chroot_sftp 755 root.root <- chroot for ALL sftp users. Perms required by sshd
      • /dev 755 root.root
        • /log 4766 root.root <- Used by rsyslog
      • /home 710 root.sftp
        • /user1 700 user1.sftp

With this setup, users in the sftp group are chrooted to /sftp_files/chroot_sftp. There is a single entry in a file in /etc/rsyslog.d/25-sftp.conf for the /sftp_files/chroot/dev/log file. Because /sftp_files/chroot_sftp/home has the unusual 710 permissions, users cannot list the directory, but they can access any file whose name they know, assuming that the permissions on that particular file allows it. Also, I create these sftp users with sftp as their only (and shared) group.

I also use public keys, so the regular /home/user1/.ssh/authorized_keys file exists. (I use /etc/skel with an empty file to have the file created with the appropriate permissions.) This could go in /sftp_files/authorized_keys/user1 instead, with authorized_keys as root.sftp 710, and user1 as user1.sftp 700. That breaks /etc/skel for the authorized_keys file, however.

I have NOT tested what follows. For your shared directories, what I would do is add a few more items:

          • /shared_dirs <- link to /shared_dirs, which inside the chroot will go to ...
      • /shared_dirs 750 root.sftp <- here. Contents visible to all, however...
        • /sd_1 770 root.sg1 <- only accessible to members of group sg1.

The link /shared_dirs is a convenience so that users don't have to remember the name of a directory that they cannot see. Alternatively, shared_dirs could also have 710 permissions, and you create a link for each shared directory that a users should be able to access.

Nathan Zook
  • 1