Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Need help creating a chroot jail for FTP users

Hi All,

Does anybody have any experience setting up chroot jails for FTP users? I would like set up the built in FTP service for Snow Leopard Server so that users only have access to to their ~/Sites folder and nothing else. I have searched all over the internet and there is no definitive answer. I would also like to make the service use SFTP so passwords are not sent in clear.

So far I have experimented with making a chroot file in the /etc directory with no success.

Any help much appreciated.

Home: iMac 27" Quad Core i7 Work: iMac 17" Core Duo, Mac OS X (10.6.3)

Posted on Oct 16, 2010 8:19 PM

Reply
15 replies

Oct 17, 2010 1:19 PM in response to shorts

Pick your battles 🙂

FTP and SFTP are unrelated, other than some similar characters in their name.

FTP is the venerable (ancient?) protocol that's insecure and a PITA to get through firewalls.

SFTP is a file transfer protocol that sits on top of SSH.

Since SFTP runs over SSH it's automatically encrypted.

chrooting FTP users shouldn't be any harder than adding their usernames to /etc/ftpchroot
Then when they log in they will be locked to their home directory. This is not the same as ~/Sites, of course, but it's a simple solution.

chrooting SSH/SFTP is a little trickier since you have to edit /etc/sshd_config and there are more considerations - for example, you probably want to disable TCP forwarding/tunneling for your chrooted users. The following example should lock a user to their home directory:

Match User joeuser
X11Forwarding no
AllowTcpForwarding no
ChrootDirectory /Users/joeuser


This disables X11 forwarding and TCP forwarding in addition to locking them to their home directory.

If you have a mass of users, you could use a Match Group... command instead, and chroot users based on their group rather than specifying individual usernames, e.g.:


Match Group Basic_users
X11Forwarding no
AllowTcpForwarding no
ChrootDirectory %h


(where SFTP interprets %h as the current user's home directory).

Oct 23, 2010 10:32 AM in response to Camelot

Camelot, I'm new at SFTP and investigating how to implement SFTP chroot on my MacMini Server 2010 running 10.6.4. Some interesting resources about SFTP chroot I found:
http://www.macresearch.org/restricted-sftp-mac-os-x-leopard
http://www.minstrel.org.uk/papers/sftp/builtin/
https://calomel.org/sftp_chroot.html

It is suggested here to change something extra in /etc/sshd_config, namely commenting out the line:
Subsystem sftp /usr/libexec/sftp-server

and adding the line:

Subsystem sftp internal-sftp

Furthermore, resources mention adding ForceCommand internal-sftp, so that the "Match block" becomes something like:

Match Group sftponly
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no

My question is: are the above Subsystem replacement and the ForceCommand addition necessary on Snow Leopard Server 10.6.4? Can you explain what the Subsystem configuration item actually does? I did not find an easy/newbie-proof explanation of it anywhere.

Message was edited by: Apple Martin

Message was edited by: Apple Martin

Jan 31, 2011 11:57 AM in response to Apple Martin

Following several other topic's hints, it still did not work out for me. Finally I 'accidentally' changed 'something' and then, boom!, I had sftp running on 10.6.6 with chrooted sftp, thus restricting an sftp client to only the indicated folder and preventing client from browsing up the whole file tree. I happened to have recorded the steps, starting from a freshly installed 10.6.6 with users 'admin' and 'uploader' made during the installation procedure and in the System Preferences/Accounts respectively. I wanted /sftp/uploader/ as the chrooted dir and this is what did it (log in as admin, start a terminal window):

+www:~ admin$ sudo su root+
+sh-3.2# cd /+
+sh-3.2# mkdir sftp+
+sh-3.2# mkdir sftp/uploader+
+sh-3.2# chmod g-w /+
+sh-3.2# chmod g-w /sftp+
+sh-3.2# chown uploader /sftp/uploader+
+sh-3.2# chmod 700 /sftp/uploader+
+sh-3.2# exit+
exit
+www:~ admin$+

I then edited /etc/sshd_conf by commenting out the /usr/libexec/sftp-server and adding

+#Subsystem sftp /usr/libexec/sftp-server+
+Subsystem sftp internal-sftp+
+Match User uploader+
+ForceCommand internal-sftp+
+X11Forwarding no+
+AllowTcpForwarding no+
+ChrootDirectory /sftp/+

Then from another computer I logged in to the sftp server using FileZilla, connecting with account details of 'uploader'. The tail of /var/log/secure.log on the server after the visit reads

+Jan 31 18:46:11 www sshd[4834]: in pam smauthenticate(): Failed to determine Kerberos principal name.+
+Jan 31 18:46:11 www sshd[4832]: Accepted keyboard-interactive/pam for uploader from 192.168.178.25 port 54019 ssh2+
+Jan 31 18:46:11 www com.apple.SecurityServer[23]: Session 0x33b70d created+
+Jan 31 18:46:11 www com.apple.SecurityServer[23]: Session 0x33b70d attributes 0x20+
+Jan 31 18:46:11 www sshd[4835]: subsystem request for sftp+

and despite some error messages, FileZilla is able to upload files and folders to /sftp/uploader/
As far as I can see, FileZilla is restricted to / , which maps to /sftp/uploader/ on the server.

Feb 14, 2011 8:31 PM in response to adiosapito

The only obvious difference I can see is that you run a mac mini SERVER and I run a mac mini. The observed behaviour ("can't log in" or "can go everywhere") I have seen too when I was asked to change the user's name. As soon as the user name did not fit the "Match User uploader" pattern spelled out in the sshd_conf file, the user could go everywhere.
My solution is a "one trick pony" in the sense that I only have one user, named uploader, who can sftp in to the computer.

Feb 14, 2011 9:39 PM in response to Apple Martin

Hi All,

Thanks for your help with this.

Martin: I found all of the links that you found but none of those methods worked.
Camelot: Excellent advice. Thanks.
eljonco: I might try your instructions and see how it goes. Thanks.

At least I know I'm not the only one who wants to get this sort of setup working. I'll take everyone's info into account and give it another shot and post back if I get it working.

Cheers,

shorts

Jun 9, 2011 3:25 PM in response to shorts

I'm still trying to find a good solution for this. I've got it to work with a single user as per this thread but I'd like it to work for an entire group. I've done the usual permissions set up as per eljonco's reply above and done this in my sshd_config:


Subsystem sftp internal-sftp


Match Group sftpGroup

X11Forwarding no

AllowTCPForwarding no

ChrootDirectory /sftp

ForceCommand internal-sftp



My account that is part of "sftpGroup" can log in but is not locked down to their directory.


sftp dir:


drwxr-xr-x 3 root wheel 102 Jun 9 14:03 sftp


dir inside sftp:


drwx------ 3 schilly wheel 102 Jun 9 14:41 schilly


I've messed with the permissions a bunch of haven't been able to get much past this. Anyone have any ideas to try?

Aug 10, 2011 4:06 AM in response to shorts

After all this time, I'm still keeping an eye on this thread. There still doesn't seem to be a definitive solution. I've stopped work on this project for the moment but it would be good if this thread was kept alive. If anybody else has got any experience with this and how to make it work (not including third party software) I (and probably the others that have joined this thread) would be very interested. Thanks again to all those participating.

Dec 18, 2011 4:24 AM in response to s-chilly

I think the real truth is that Mac OS X Server IMO lacks the the ability to provide people to run enterprise grade web hosting. The rest of the system is great - DNS, Mail, Web... I'm not an expert but I've tested other linux systems that have allowed me to create a chroot jail that works exactly how I want it...


That is -


- You can create virtual hosts (this works)

- They are chrooted to thier ~username/Sites folder (does'nt work without mass customisation)

- FTP is not secure there should be some way of enabling SFTP for a user without going through all this stuff.


It seems the BIG difference is Apple have created a great GUI to handle everything but CHROOT users and SFTP.


All the stuff I learnt about UNIX has helped me get this working on LINUX systems but Apple doesn't seem to catering for this style of server.


Man... The list could go on. Is there something I'm missing? Do I sould like a whinging noob or should I just use some other OS?


One thing I've found with Linux systems is there is repositories for software. Is macports the equivilent for Mac OS X? Maybe the answer is there?


Theres also one thing that I've noticed that can block user access: Check Server Admin and make sure that the user has Remote Login Access. Correct me if I'm wrong but if you dont give Remote Login Access to the specified user, SFTP or SSH access will not work.


There is a new post about chrooting ftp here. I tested it and unless I made some mistake, the guide worked with these caveats:


When I connect with an FTP Client such as fetch, I can still navigate to / (root) and see all of the root filesystem but I definitely cannot write outside the chrooted folder. Thats half of the desired outcome. What I'm really looking for is the user is jailed to their ~/Sites folder and when they SFTP from terminal or an FTP client, they only have access to thier ~/Sites foler and cannot see anything other than that. Thier ~/Sites foler is thier root folder.


Last thought is: I haven't started the FTP server in server admin and I know it gives you the ability to restrict FTP users to their home folder. But I dont think this has anything to do with it because FTP and SFTP are two completely different beasts!


@Camelot.. sureley you have some comments about all this stuff.


Thanks.

Need help creating a chroot jail for FTP users

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.