How to set up and chroot SFTP users with OpenSSH in Ubuntu

Thanks the author of this link: http://www.ericstockwell.com/?p=54

I had been wanting to set up an encrypted-transaction FTP server for a while (SFTP) in a chrooted environment, so I did a few hours of half-baked-blog parsing and keyboard-pounding in order to figure this out in a way that would work consistently, even if it isn’t 100% efficient. Your noob-radar should be flashing right about now ;). Since version 4.8, openssh has had the ability to (fairly) easily chroot sftp users into a specified directory using a new sshd_config directive, ChrootDirectory. The purpose of this guide is to demonstrate how to set up a simple chrooted sftp system from square one implementing this self-contained chroot mechanism (using only openssh without the need for rssh), and how to add users under this paradigm.

(1) Installation and initial configuration

It is possible that ssh is not installed, so:

$ sudo apt-get install ssh

We need to configure the sftp subsystem to use the internal sftp module. Open

/etc/ssh/sshd_config

in a text editor (you will probably have to use “sudo”), and find the line that starts with “Subsystem sftp”. Comment out (or delete) this line, and replace it with:

Subsystem sftp internal-sftp

Save and exit your editor.

(2) User Setup

This section should be repeated for each user to whom you grant sftp-only access.

Because sftp (as included with openssh) wraps around ssh, your users are going to need system accounts. Let’s prepare a user named “johndoe” (replace “johndoe” with whatever new user account you wish). The user “johndoe” should, in this case, only be able to log in using sftp (as opposed to ssh) once we’re done.

$ sudo mkdir /home/johndoe
$ sudo useradd johndoe

We’ll have to set their home directory permissions appropriately. It’s important that root owns this and that its group ID is identical to the username, and that the permissions are set so that only root can write:

$ sudo chown root:johndoe /home/johndoe
$ sudo chmod 755 /home/johndoe

Force the normal login directory just in case:

$ sudo usermod -d /home/johndoe johndoe

Now give him a password:

$ sudo passwd johndoe

Set the new user a dummy shell (so they don’t have real shell access).

$ sudo usermod -s /bin/false johndoe

Now we need to indicate that this particular user must be jailed into their home directory. Once again, open /etc/ssh/sshd_config in a text editor, and add the following at the end of the file:

Match User johndoe
      ChrootDirectory /home/johndoe
      ForceCommand internal-sftp

Now, user johndoe should have read access to his home directory. Let’s give him a place to upload stuff:

$ sudo mkdir /home/johndoe/upload
$ sudo chown johndoe:johndoe /home/johndoe/upload
$ sudo chmod 755 /home/johndoe/upload

Done! Restart the ssh daemon (run this any time you want changes to become effective):

sudo /etc/init.d/ssh restart

(3) Giving SFTP users read access to some other directory

As an interesting aside, let’s say you (the sysadmin) have a common info/media/data directory you wish to share with your sftp users without actually copying all that data over (or allowing it to be edited/deleted/corrupted). We can do this by mounting it read-only somewhere in their login directory. They’re going to need a place to get to it:

$ sudo mkdir /home/johndoe/readonly

Now we mount our directory of choice (in this example, /home/sysadmin/junk/shared-data) as read-only in said folder:

$ sudo mount -r --bind /home/sysadmin/junk/shared-data /home/johndoe/readonly

It will probably help to have this happen automatically on startup. Anything added to rc.local will run as root at startup, so there is no need to indicate ’sudo’. If you have multiple users (or even just one) it helps to add something like this to /etc/rc.local (before the “exit 0″ line of course):

for user in johndoe marysue someguy
do
mount -r --bind /home/sysadmin/junk/shared-data /home/$user/readonly
done

Note: You cannot mount more than one folder/device/partition/netshare in a particular location. Doing so won’t damage anything, but the mount point will only display the object mounted last in sequence. There are other constraints which you may discover, but those are beyond the scope of this guide (and they make me drink).