Set startup folder for SFTP to be other than /home/username is throwing me permission issues

Question

I just installed a CentOS-based to serve as an SFTP server.

I need all incoming files to go /mnt/inbound/ folder, so I want to ensure that every user from this host that logs in via SFTP gets /mnt/inbound/ as their starting point, and I want to ensure that they cannot go anywhere else.

I got as far as being able to connect with a test user using an SFTP client and ensuring the user is jailed to their respective folder -- but user cannot upload files...

Here is what I have done so far:

1. Create a group called sftponly for to contain all customer inbound users:

$ groupadd sftponly

2. Modify /etc/ssh/sshd_config to use the internal-sftp Subsystem:

# Enable built-in implementation of SFTP Subsystem sftp internal-sftp

3. Add the following at the end of sshd_conf:

Match Group sftponly # Force the connection to use the built-in SFTP support ForceCommand internal-sftp # Chroot the connection into the specified directory ChrootDirectory /mnt/inbound/%u # Disable network tunneling PermitTunnel no # Disable authentication agent forwarding AllowAgentForwarding no # Disable TCP connection forwarding AllowTcpForwarding no # Disable X11 remote desktop forwarding X11Forwarding no

4. Adding a user to use sftp:

$ sudo useradd -g sftponly testuser

5. must create the user folder under /mnt/inbound:

$ sudo mkdir /mnt/inbound/testuser

I can now use FileZilla (or any other client) to do an SFTP connection to this host, and I can see that the user is jailed to the /mnt/inbound/testuser folder. However the user cannot upload files.

I have tried changing the rights of the /mnt/inbound/test folder so that the user test can get access to it, but that breaks the user's ability to connect via SFTP.

I cannot change the owner of the folder to other than root, so how can I ensure that the user can read and write into their respective folder?

I have seen several attempts to answer similar questions around the internet (including StackExchange) but all seem to be missing a point or two -- since I always end up with a Broken SFTP setup when I try to follow the instructions provided in the answers.

Regards, P.

Answer 1

Right I managed to get some advice at #openssh IRC channel and here is what was missing from my solution:

The directory specified in ChrootDirectory must be owned by root. Since in the above sshd_config file I have specified the %u variable so every user has their own root directory base on their username (e.g. testuser would be /mnt/inbound/testuser/) then all of those directories must be owned by root. This is in fact the default when I create the directories doing sudo mkdir /mnt/inbound/<username> since the mkdir command is elevate via sudo.

So what I needed to do is to create a sub-directory under /mnt/inbound/<username> and give that directory permission for the user. In my case I called this directory uploads.

So I changed my configuration slightly as follows:

Match Group sftponly # Chroot the connection into the specified directory ChrootDirectory /mnt/inbound/%u # Force the connection to use the built-in SFTP support ForceCommand internal-sftp -d /uploads

The ForceCommand line has been changed to include -d /uploads, meaning that the default directory after the user logs-in in is /uploads. Note that it is /uploads and not /mnt/inbound/%u/uploads because it takes into account that /mnt/inbound/%u has been specified as the new root in the previous line in the config.

If I do ChrootDirectory /mnt/inbound/ an then specify ForceCommand internal-sftp -d /%u, I could make the /mnt/inbound/<username> folder be owned by the end-user since /mnt/inbound is now the new root directory that must be owned by the root account. However users would be able to navigate to the parent folder and see the directory names of all other accounts. I decided against that :)

Answer 2

Thank you for posting your updated solution, @pmdci. I had to make a slight modification on my side to make it work in the /home directory for a given user in Ubuntu 18 - yes this is somewhat counter to your specific goal of using a non-home folder, but may help others trying to do similar.

1. Make a new system user (I'm calling this user "yournewuser" in this example) for your SFTP access (Ubuntu should automatically generate the home directory in the "adduser" input process), set the password, and add new user to group that you will be setting as the control group for SFTP, I'm calling this "yoursftpgroup" in this example.

2. If you do not want that user to login, set the following: sudo usermod -s /sbin/nologon yournewuser

3. As you pointed out, make sure the directory for the new user is owned by root with a "CHOWN root". Yes this should be done and sudo should take care of this, but I did this explicitly just in case...

4. Set the permissions (CHMOD) to 755 for this new user's directory "/home/newuser/" I did not have to use the -R switch (watch out with that one) Note: this should be the same permissions for the other users - at least in my case. Failure to do this will cause an access denied issue at SFTP logon (tested with WinSCP)

5. Make a new directory for your uploads in the /home/yournewuser/uploads. You likely had to do this as sudo, so now you need to shift ownership back to that user with yournewuser:yoursftpgroup CHOWN /home/yournewuser/uploads

6. Now set the permissions of that directory to 700: CHMOD 700 /home/yournewuser/uploads.

7. Change the /etc/ssh/sshd_config file with the following lines at the end (just a tweak of your lines for this case):

    Subsystem       sftp    internal-sftp
   
    Match Group yoursftpgroup
   
    ChrootDirectory /home/%u
   
    X11Forwarding no
   
    AllowTcpForwarding no
   
    ForceCommand internal-sftp -d /uploads
   

8. Restart the SSH service with: sudo service ssh restart

9. Test access

Answer 3

You need to chown /mnt/inbound folder to the root account and then create other users folders same as their names in the inbound folder and give them full rights to them.

You can use chroot option so each user will only have it's own folder and can't go up.

But you can't have common upload folder using that solution.