Restricting SFTP (jail/chroot)
This is an installation reference for setting up jailed (chroot) sftp accounts.
Two common options exist for creating a chrooted environment to restrict SFTP users from traversing outside of their home directories. The first is compiling Open ssh from scratch and replacing the SFTP and one other executable with third party software. This would be a nightmare for patching/upgrading the ssh distribution. The second method, and the one this will be referencing from now on is Scponly. This script acts as a replacement shell that is executed after the standard SSH daemon authenticates the users account, avoiding any custom scripting of the OpenSSH distribution. Since scponly is a replacement shell, it is not a global change to all accounts. This allows the system administrator to pick and choose what with be chrooted.
Installation
Log into the system as root and follow these directions:
# mkdir /build # cd /build # wget http://internap.dl.sourceforge.net/sourceforge/scponly/scponly-4.8.tgz # gunzip -d scponly-4.8.tgz # tar -xvf scponly-4.8.tar # cd cd scponly-4.8 # ./configure --enable-chrooted-binary --disable-scp-compat --disable-winscp-compat --disable-wildcards # make ; make install # echo /usr/local/sbin/scponlyc >> /etc/shells # either type 'make jail' or execute './setup_chroot.sh'
The two commands ‘make jail’ and ‘./setup_chroot.sh’ with walk you through creating a jailed user account. The script will automatically create the users home directory and copy over all required libraries. After the script finishes, the following directories will be present:
/usr /lib /incoming /etc
The only writable (where users will put data) directory is the /incoming folder (by default). The other directories including the chrooted ‘/’ (root) directory are all in the users chroot environment and are not writable by the individual user. Incoming directory will not show up if the “writable sub directory” option was changed from the default when running ‘make jail’ or ‘./setup_chroot.sh’
Note: Again, this is done in a way that ssh can be upgraded and or patched without affecting the sftp jail. Definitely want to avoid the headache of manual patching of systems and keeping track of the “one off” configurations.

To fix the /dev/null issue in RedHat and Centos 5.x versions please see:
http://blog.colovirt.com/2009/03/17/linuxsecurity-scponly-sftp-fix-for-redhat-and-centos-5x-and-possibly-fedora/
kcollo said this on March 17, 2009 at 1:17 pm