Many thanks to Bryan Irvine for putting together the OpenBSD instructions, and to a wide variety of different people that have helped me tune the generic instructions.
||OpenBSD 4.0 Instructions
||Download the latest OpenSSH 'portable' source tarball from OpenSSH.org
||Download the source from CVS following OpenBSD instructions. You'll end up with the source tree in /usr/src
||Extract the source files to a directory somewhere.
||Included in Step 1
||In the source directory, replace sftp-server.c with my modified version - my changes are commented within the file itself (search for 'Minstrel') so you can see what I'm up to.
Note: another change I make before compilation is to change version.h so that OpenSSH no longer provides detailed version information, but then I'm just paranoid!
|Replace /usr/src/usr.bin/ssh/sftp-server.c with the OpenBSD variant from Bryan, instead of mine (which is based on the 'portable' code).
||Do the usual ./configure with the relevant switches for your environment (for example, I use --with-tcp-wrappers - see the note at the end of the page)
||CD to /usr/src/usr.bin/ssh - ./configure is not required, unless you want to add switches
Note to Solaris users: I have had the odd problem at this step in the past, which seems to be down to the usual Solaris conflicts between Sun and Gnu binaries. If you get an error in the last stages of the 'install' process, ending with the word 'Killed', try the following:
PATH=/usr/ccs/bin:$PATH ; export PATH
Then make install again.
|CD to /usr/src/usr.bin/ssh/sftp-server/ and then make install
||'chroot' can only be executed by the root account, so sftp-server needs to run with root privileges - therefore use chmod +s /usr/local/libexec/sftp-server (unless your system places the sftp-server binary somewhere else).
|Hoorah! You now have an sftp-server executable capable of chroot'ing users. If you previously had SSH installed on your system, you might also want to double-check at this point that the path to sftp-server in your sshd_config file is correct.
The main SSH shell program is not jailed, so next we need next to restrict the users to SFTP only. I did this using a simple C program to create a new shell that 'wraps' sftp-server and nothing else. An alternative is to use sftp-server itself as the user's shell, but I understand there are ways a user could execute arbitrary commands if this was the case.
||Download sftpsh.c to your system - this is the program I originally found, and I haven't altered it in any way, other than the required modifications mentioned below.
||Edit sftpsh.c and modify the following lines to fit your environment (see the comments in the file itself):
#define SFTP_BINARY "/usr/local/libexec/sftp-server"
#define SFTP_EXNAME "sftp-server"
#define SFTP_ARGS ""
||Compile this program using the command gcc -O2 sftpsh.c -o sftpsh
||Copy the new shell to your system path, using the command cp sftpsh /bin
||Make sure the new shell is recognised by the system, by adding it to /etc/shells - use the command echo /bin/sftpsh >> /etc/shells
||Now, configure your users' accounts as follows (don't forget to do this with new users as well):
- Set their shell to /bin/sftpsh
- Use the chroot 'magic token' (a full stop) in their home directory setting, e.g. /home/username/./ - the path before the '.' becomes the user's root directory once they connect using SFTP, whilst the path after the '.' defines the directory they are initially dropped into once logged in.
- Set the permissions on /home/username/ so that they can modify their files (e.g. chown -R username:users /home/username).
- Ensure the default UMASK is set appropriately - I found my users got confused if their files didn't automatically set themselves to rwxr-xr-x (755), so I added CMASK=022 to /etc/default/login
||Test the setup (you will probably need to HUP your SSH daemon first, or start it up if it isn't already). Use sftp firstname.lastname@example.org and make sure you can't change directory out of the chroot'd environment. Also check access is denied when using ssh email@example.com
Finished! You should now have a tidy, restricted environment for those pesky users that will insist on uploading files to their Web sites!