/ Blog Post Necromancy

Setting up a Jailed (Chrooted) SFTP Server on CentOS 6.0

This is for a Term Project I had to do for Comp 270 at Camosun College. Unfortunately, the wiki provided as part of Moodle (EufurtWiki) is functionally useless.

I created a chrooted sftp environment on my Comp270 server to allow users with Apache virtual hosts to connect securely and add junk to their sites.

Notes and Annoyances

Here are some things I discovered during the process:

  • SELinux is annoying. Set it to 'permissive' unless you know how to deal with it; I don't, because we didn't learn about it, and I'm not spending another 5 hours figuring it out - I already lost 5 hours figuring out that it was the bloody problem.
  • Directory structure - put the chroot base somewhere on its own; root has to own everything up to and including the chroot, so don't put it somewhere where that will break stuff.
  • Ownership and permissions - if you're using this for a virtualhost environment, apache has to be able to read every part of the path leading up to the httpdocs folders, so 755 all 'round. Doesn't seem to matter who owns the files, as long as they're 644.

Install OpenSSH

In my case, this required removing the existing install to get a clean slate, and then reinstalling. The install is simply done via:

sudo yum install openssh-server

While we're here, lets create the vhosts root too:

sudo mkdir /vhosts

Create sftp Users Group

This was easy. I chose vhosts as the group name because it made its purpose crystal clear.

sudo groupadd vhosts

Add Users

I added users for my existing vhosts, hera and isis, using -d to specify the home directory. Let's add hera now (isis would obviously be the same, but with values specific to its case).

First, we create the user:

sudo useradd -d /vhosts/hera hera

Then, we add the user to the vhosts group:

sudo usermod -g vhosts hera

Next, we add a password for the user:

sudo passwd hera

Finally, we set the user's shell to /bin/false so they can't do anything 'shelly':

sudo usermod -s /bin/false hera

Modify sshd_config

We need to set OpenSSH up to control what happens with these vhosts users, so there are a few changes to make in sshd_config:

First, we need to change the sftp subsystem, so find this:

# override default of no subsystems
Subsystem       sftp    /usr/libexec/openssh/sftp-server

Comment out the existing Subsystem line, and add this below it:

Subsystem       sftp    internal-sftp

It should now look like this:

# override default of no subsystems
#Subsystem       sftp    /usr/libexec/openssh/sftp-server
Subsystem       sftp    internal-sftp 

We also need to add a Match section to do stuff specific to the sftp users, so at the very bottom of the file, add this:

Match group vhosts
    X11Forwarding no
    ChrootDirectory /vhosts/%u
    AllowTcpForwarding no
    ForceCommand internal-sftp

The ChrootDirectory line locks them into /vhosts/[username], and ForceCommand says that they must use internal-sftp.

Configure vhosts directory

Because the chroot environment is run by root, we need to ensure that the permissions of the users' folders are correct. the vhost root - and all folders above it - must be owned by root:root.

sudo chown root:root /vhosts
sudo chmod 755 /vhosts

I'd created the vhosts directories earlier (not in the scope of this write-up, but Google it - there's lots out there), so for this exercise I added httpdocs and logs subdirectories which will be the web root & logfile spot respectively, and updated the httpd.conf to point there.

So, now we just need to make sure ownerships are correct. The following recursively sets everything in /vhosts/hera and below to hera:apache (apache needs to muck around in here, after all), and then sets the root (/vhosts/hera) to root:root:

sudo chown hera:apache -R /vhosts/hera
sudo chown root:root /vhosts/hera
sudo chmod 755 /vhosts/hera

You might want to make the logs directory owned by root:apache so that the user can't edit them:

sudo chown root:apache -R /vhosts/hera/logs


That was a grand adventure - I actually feel like I could set up a virtual hosting environment now, secure in the knowledge that each user can't muck around with things they're not supposed to.

Hopefully the adventure worked for you too!