Currently Being ModeratedOct 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
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
(where SFTP interprets %h as the current user's home directory).Mac OS X (10.6.4)
Currently Being ModeratedOct 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:
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
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 MartinMacMini Server 2010, Mac OS X (10.6.4)
Currently Being ModeratedJan 14, 2011 12:06 PM (in response to Apple Martin)It has been some time since I posted the above question.
Does anyone know whether
Subsystem sftp internal-sftp
need to be added to /etc/sshd_config for a sftp chroot?MacMini Server 2010, Mac OS X (10.6.5)
Currently Being ModeratedJan 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+
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+
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: in pamsmauthenticate(): Failed to determine Kerberos principal name.+
+Jan 31 18:46:11 www sshd: Accepted keyboard-interactive/pam for uploader from 192.168.178.25 port 54019 ssh2+
+Jan 31 18:46:11 www com.apple.SecurityServer: Session 0x33b70d created+
+Jan 31 18:46:11 www com.apple.SecurityServer: Session 0x33b70d attributes 0x20+
+Jan 31 18:46:11 www sshd: 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.many, Mac OS X (10.6.6), mac mini
Currently Being ModeratedFeb 14, 2011 3:33 PM (in response to eljonco)I tried the your process exactly and whenever Filezilla tries to log in I get:
Error: Server unexpectedly closed network connection
Error: Could not connect to server
As soon as I undo the sshd_config changes, it works fine but you can go anywhere in the directory. Any other ideas of how to create a jail?Mac Mini Server, Mac OS X (10.6.6)
Currently Being ModeratedFeb 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.many, Mac OS X (10.5.7), PB G24 MBP iBook G4 flatpanel Bondy Blue Snowwhite
Currently Being ModeratedFeb 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.
shortsHome: iMac 27" Quad Core i7 Work: iMac 17" Core Duo, Mac OS X (10.6.3)
Currently Being ModeratedMay 22, 2011 2:13 AM (in response to shorts)
Currently Being ModeratedJun 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
My account that is part of "sftpGroup" can log in but is not locked down to their directory.
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?
Currently Being ModeratedAug 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.
Currently Being ModeratedAug 10, 2011 8:10 AM (in response to shorts)
I've got a solid working solution now which I've been meaning to write up a guide on for my blog. It definitely wasn't easy.
Not a lot of time in the summer right now but I'll keep you posted on when it goes live.
Currently Being ModeratedOct 15, 2011 7:55 AM (in response to s-chilly)
I thing I have a simple solution for all this...
Via Workgroup manager....
Go to the home tab and add click on + button...
1) Left empty the AFp path
2) lest empty Path to Home folder
3) Give the full path that you want !!!
4) Click OK
5) DO NOT press the button creat a Home Folder
Done !!!! Be smile !!!
Currently Being ModeratedDec 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.
Currently Being ModeratedDec 18, 2011 4:38 AM (in response to ath2k2004)
this is still giving access to view the / directory... good solution but not complete. I will still Be Smile though