We've found a workaround recently that goes like this:
/etc/ssh/sshd_config:
... Subsystem sftp internal-sftp Match Group sftponly ChrootDirectory /home AllowTCPForwarding no X11Forwarding no ForceCommand internal-sftp
directory permissions:
root@server:~ # chown root:root /home root@server:~ # chmod 111 /home root@server:~ # chmod 700 /home/*
Now /home satisfies the requirements for ChrootDirectory and can't be listed by restricted users, but sftponly users will not be able to log in if their home directories are set up as usual (/home/$LOGNAME): under the chrooted environment their home directories aren't inside /home but directly under root (/).
workaround 1
Set restricted users' homes to how they appear under chroot:
root@server:~ # usermod -d /username username
caveate 1
If any of the unrestricted users or some administration script uses bash's tilde expansion like ~username it will expand to /username now, which isn't what is meant.
Also the admin that creates sftponly users has to remember to use non-default home. Solveable with a script. Which the admin has to remember to use.
workaround 2
This is an alternative to the previous one that we ended up using:
root@server:~ # ln -s . /home/home
That is create a symlink inside /home to its own dirname. Now under chroot /home/username points to the same directory as without chroot. For restricted user logged in with sftp it would appear as /username. This directory is writable to its owner (restricted user). Restricted user can't list its parent or home directories of any of the siblings by name.
The only thing special about an sftponly user is its participation in the sftponly group. We found it easier to deal with than the workaround 1.
caveates 2
- You can't have user named 'home' with a home directory
/home/home - You have to be careful with scripts that traverse
/home hierarchy and follow symlinks.
chrooted users own theirChrootDirectory? Can they access it ?