openssh/sftp-server virtual chroot does not work

Question

By example, when connect to ssh and execute /usr/libexec/openssh/sftp-server -d /opt/files can get / root directory from a sshfs connection.

By example: have a test user and from authorized_keys have two access, one with all access and other with limited access, by example:

restrict,command="/usr/libexec/openssh/sftp-server -d /opt/files" ssh-rsa AAA...

But with this key can mount the root directory:

# mkdir /mnt/remote
# sshfs test@hostname:/ /mnt/remote
# ls /mnt/remote
bin boot dev etc home ...

I am trying to create an integration with a custom software developed in python, that is why I am trying with a single user instead of chrooting with different users and different permissions, I want to do it with a single user delegating access to different directories according to each key.

Answer 1

Just having the -d option for sftp-server will not cause the session to be chrooted.

sftp-server has no special privileges on its own, and the chroot() system call requires root privileges (or a specific CAP_SYS_CHROOT capability, if separate capabilities are being used). So it is actually impossible for sftp-server to perform an actual chroot operation, unless it is being run as root.

The sftp-server(8) man page says:

-d start_directory

specifies an alternate starting directory for users. [...] The default is to use the user's home directory. This option is useful in conjunction with the sshd_config(5) ChrootDirectory option.

So your sftp-server -d /opt/files is not a "virtual chroot". It is nothing more than a cd /opt/files just before the control of the SFTP session is handed to the remote client.

To chroot just one particular user, you could do something like this at the end of your /etc/ssh/sshd_config file:

Match User test
ChrootDirectory /opt/files

If you plan to do actual chrooting, you should read the description of the ChrootDirectory option very carefully: the requirements for the directory used as ChrootDirectory are quite strict.

Unfortunately it seems you cannot use the key to determine the directory the session will be chrooted to: although the ChrootDirectory option accepts some %-tokens, the sshd_config(5) man page of even the latest version of OpenSSH says:

ChrootDirectory accepts the tokens %%, %h, %U, and %u.

And those four tokens mean, respectively: a literal % character, user's home directory, the numeric user ID, and the username.

If your goal is e.g. to have the Python application prepare files for multiple customers, that's what user groups are for! On many modern Linux distributions, each user is created along with a group dedicated for that user, with a group name equal to the username.

You could set up your user accounts this way:

User	Primary group	Secondary groups
pythonapp	pythonapp	test1,test2,test3...
test1	test1	(none)
test2	test2	(none)
test3	test3	(none)
...	...	...

If the test1, test2, test3 etc. users have their home directories set up with permissions of at least 710 (drwx--x---) and each home directory has a group-writeable sub-directory with permissions 2770 (drwxrws---), then user pythonapp will have access to all those group-writeable sub-directories, but the test... users will have no access to each others' home directories nor the group-writeable directories within them, because there will be no common group membership between the test... users. The setgid bit on the group-writeable subdirectories will ensure that any files created by the pythonapp user will get assigned to the user-specific group so the test... users will never even see the name of the pythonapp group.

Of course, if you have hundreds or thousands of customers, this approach can be difficult to scale that far.