Looking around online, I found several instances of people wanting to chroot sftp on 10.5 server. The purpose being, they want to give access to sftp for users they may not trust, and want to keep them where they belong over sftp.
Unfortunately, there were a couple pieces missing from the instructions. So, thought I would fix that.
First, make a backup of /etc/sshd_config. While it should be easy enough to back out these changes, it’s just good practice to make a backup.
Second, create a directory for the “jail”. In my case, this was in /Volumes/Data/Websites/username.
The key here is that all directories up to and including the username directory must be read only by everyone but root when it comes to POSIX directories. So / would need to be root:group, and something like rwxr-xr-x. That goes for /Volumes, /Volumes/Data and /Volumes/Data/Websites.
The rest is all in the /etc/sshd_config
Comment out (with a #):
Subsystem sftp /usr/libexec/sftp-server
Subsystem sftp internal-sftp
At the end of the sshd_config, add:
Match User username
Or, if you want to enforce on a group:
Match Group usergroup
You can add both, and ssh will read from first to last. So, if you want specific users to go to specific folders, you can add them first, then end with a group policy.
Lastly, while testing this, make sure to watch /var/log/secure.log. You’ll see errors there when it doesn’t work. My problem, when working on this, was the write ability for users other than root on the parent directories. I had to systematically remove group and other write before it would work.
Those errors looked like:
fatal: bad ownership or modes for chroot directory component "/"
In the case of the root directory.
Lastly, this will remove SSH capability for the user specified. They will only be able to SFTP, but they’ll be locked into the directory specified. Great for a random student groups, in my case, that need to have a website, but you don’t necessarily want running wild on your system.