Skip navigation

Need help creating a chroot jail for FTP users

8371 Views 15 Replies Latest reply: Oct 9, 2012 9:02 PM by shorts RSS
1 2 Previous Next
shorts Level 2 Level 2 (455 points)
Currently Being Moderated
Oct 16, 2010 8:19 PM
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)
  • Camelot Level 8 Level 8 (45,670 points)
    Currently Being Moderated
    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).
    Mac OS X (10.6.4)
  • Apple Martin Calculating status...
    Currently Being Moderated
    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
    MacMini Server 2010, Mac OS X (10.6.4)
  • Apple Martin Level 1 Level 1 (5 points)
    Currently Being Moderated
    Jan 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

    and

    ForceCommand internal-sftp

    need to be added to /etc/sshd_config for a sftp chroot?
    MacMini Server 2010, Mac OS X (10.6.5)
  • eljonco Level 1 Level 1 (20 points)
    Currently Being Moderated
    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 pamsmauthenticate(): 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.
    many, Mac OS X (10.6.6), mac mini
  • adiosapito Calculating status...
    Currently Being Moderated
    Feb 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)
  • eljonco Level 1 Level 1 (20 points)
    Currently Being Moderated
    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.
    many, Mac OS X (10.5.7), PB G24 MBP iBook G4 flatpanel Bondy Blue Snowwhite
  • dadaov Calculating status...
    Currently Being Moderated
    May 22, 2011 2:13 AM (in response to shorts)

    This can help. In my console I had :

    fatal: bad ownership or modes for chroot directory component "/Volumes/"

    And I was unable to properly fix the ownership of /Volumes through terminal. I did a simple "cmd +i" on /Volumes and I clean up the authorization.

    Look at the screen capture, before & after.

    Capture 1.png

    Capture 2.png

  • s-chilly Calculating status...
    Currently Being Moderated
    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?

  • s-chilly Level 1 Level 1 (0 points)
    Currently Being Moderated
    Aug 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.

  • ath2k2004 Calculating status...
    Currently Being Moderated
    Oct 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

    6) Save

     

    Done !!!! Be smile !!!

1 2 Previous Next

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.