HOWTO native openssh chroot and SFTP

[m27315]

Last Edit: August 8, 2008

Objective: Provide a transfer mechanism that is encrypted (SSL/SSH style), locks users to a jail (so they cannot browse your entire file system), and does not require you to maintain copies of libraries inside the jail (zero maintenance).

Solution: Use the SFTP subsystem of openssh, along with its new, native chroot jail feature.

HOWTO:

1. Make sure you are "root" (for the newbs)
   
   

   Code:

   # su - (enter root's password)

   
   
2. Currently, the prod version of openssh in portage (July 2, 2008: net-misc/openssh-4.7_p1-r6) does not contain the native chroot feature. Only versions 4.9, 5.0 and greater have this feature. You will have to upgrade to an "unstable" version of openssh, although this should become unnecessary at some later date:
   
   

   Code:

   # echo "net-misc/openssh ~amd64" >> /etc/portage/package.keywords

   
   
3. Install the latest version of openssh:
   
   

   Code:

   # emerge -pvt openssh These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild   U   ] net-misc/openssh-5.0_p1-r1  USE="X pam tcpd -X509 -hpn -kerberos -ldap -libedit (-selinux) -skey -smartcard -static" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB (sanity check the various ebuilds) # emerge openssh

   
   
4. One time setup:
   
   Create an "sftponly" group (to be used later):
   
   

   Code:

   # groupadd sftponly

   
   Modify SSH config (/etc/ssh/sshd_config):
   
   

   Code:

   Subsystem       sftp    internal-sftp Match Group sftponly         ChrootDirectory /home/%u         ForceCommand internal-sftp         AllowTcpForwarding no

   
   This enables the native, internal SFTP server. It forces any user in the group "sftponly" to use the SFTP server, enables the native chroot feature for their home space, and it disables TCP forwarding.
   
   Don't forget to restart ssh and add it to your box start-up, if you have not already:
   
   

   Code:

   # /etc/init.d/sshd restart # rc-update add sshd default

   
   
5. Optional, but handy one-time setup:
   
   Using your favorite text editor, create this bash script to create users:
   
   /root/bin/create_sftp_user.sh
   

   Code:

   #!/bin/bash user=$1 if [ ! $user ] then     echo "(E) create_sftp_user.sh: No user specified!"     echo -e "\nUsage:\n\n\tcreate_sftp_user.sh <username>"     exit 1 fi # OPTION A:  Choose visible, writable user directory # OPTION A1:  username #writable_dir=$user # OPTION A2:  common convention, "public" writable_dir=public # Create User: # OPTION B:  Choose shell # OPTION B1: Use /bin/false as shell - requires for PAM either: #            1) Removal of 'auth       required     pam_shells.so' from: #               /etc/pam.d/sshd #            2) Add /bin/false to acceptable shells: #               echo '/bin/false' >> /etc/shells useradd -g sftponly -s /bin/false -d /$writable_dir $user # OPTION B2: Use /bin/bash as shell #useradd -g sftponly -s /bin/bash -d /$writable_dir $user # create user's home space mkdir /home/$user # make root owner of user's home - required by openssh for chroot feature chown root:root /home/$user # ensure nobody can write but root - required by openssh for chroot feature chmod 755 /home/$user # make writable dir for user mkdir /home/$user/$writable_dir # change owner of writable dir to user chown $user:sftponly /home/$user/$writable_dir # ensure the correct write permissions for user chmod 755 /home/$user/$writable_dir # OPTION C:  Choose password entry method # OPTION C1:  Use hard-coded password - no interaction #             set default password to "newP@$$w0rd" echo -e "newP@\$\$w0rd\nnewP@\$\$w0rd" | passwd -q $user >& /dev/null # OPTION C2:  Prompt user for password with confirmation # passwd $user # Verify /etc/passwd entry echo -e "\nFinished. Here's the new line:\n\n" `grep $user /etc/passwd` # exit successfully exit 0

   
   You have 3 groups of options, which are controlled by comments:
   
   1. Name of user's visible home dir (username, "public", etc.)
      
   2. Login shell: /bin/false or /bin/bash - /bin/false is a more secure "shell", but requires relaxation of shell restriction in pam, which might open door for other account. I'm no security expert, but the risk seems minuscule to me, either way.
      
   3. Password entry method - hard-coded or interactive.
   
   Don't forget to make your script editable:
   
   

   Code:

   # chmod u+x ~/bin/create_sftp_user.sh

   
   
6. Every time you want to create a new user with chrooted sftponly access, simply use the above script:
   
   

   Code:

   # ~/bin/create_sftp_user.sh <username> New UNIX password: Retype new UNIX password: passwd: password updated successfully

   
   Of course, you could hide the "passwd" output with a redirect to /dev/null, but I kind of like seeing the output. ... You could also expose more internal options as command line arguments, like making the "writable_dir" optionally specified, or providing the password on the command line, etc. But, this is good enough for me.
   
   
7. You're done! Try logging in with WinSCP or any other SFTP client. All SSH clients should hang after entering the password, or produce "Access denied".

The best part is you do not have copy and maintain various libraries and binaries any more! The complete chroot functionality is now handled, and maintained inside openssh! Just by simply keeping openssh up to date, you maintain the entire chroot-SFTP process!

Resources:
http://www.minstrel.org.uk/papers/sftp/builtin.html
http://adamsworld.name/chrootjail5.php

HTH!

[infernus]

Alright. After a little trial and error I got it working (and with /bin/false too). Here are my files (I changed a few things)..

/etc/ssh/sshd_config:

[m27315]

Thanks for the tip on PAM! Removing that line allowed me to use /bin/false. Doing a little reading, I realized that I could also add "/bin/false" to "/etc/shells", but that would relax the shell restriction for all PAM authentication services, including login. So, I opted to just remove the line from PAM's sshd config. ... Even still, this method seems like it might increase the risk of other users (apache, mail, portage, etc.) from passing this PAM requirement and bring a hacker one step closer, since these users with the /bin/false shell would have otherwise been kicked out at this point. ... Really, I think it's an academic discussion, since the shell (/bin/false) has no capability, but I thought it was interesting.

BTW, I incorporated several of your suggestions. The only suggestion that I did not incorporate is the definition of the user's home. FWIW, here's why I did it the above way:

During SFTP login, the chroot feature is activated before the user is dropped into their home directory. So, if you set a user's chroot jail to their home directory, then their home directory will not exist after chroot, unless you build a duplicate /home/$user directory inside the chroot jail.

Personally, I don't like the extra levels of directory. I want as few directories as possible inside the chroot jail, and I want the user to be dropped into their writable home directory immediately after login. So, I set their home directory during user creation to be the writable dir, with respect to the chroot jail. This prohibits me from using the "%h" variable in the sshd_config, but that is easily overcome using the "/home/%u" convention. This way, I have minimal files & folders inside the jail, and the user does not have to change directories to start uploading files. ... Just a personal preference for a minor convenience.

Thanks again for the help! It is much appreciated!!

[infernus]

Glad I could help. Good luck with it. And thanks for the idea. I'm using it on my own machine now
_________________
--
Sal.

Linux latitude 2.6.25-hardened-r4 #1 SMP Sat Aug 23 15:23:14 EDT 2008 i686 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz GenuineIntel GNU/Linux

[Anarcho]

I would suggest that it might be better zu chroot to /home/ instead of /home/$user.

/home is already only writable by root so no changes here. But as the home-dir is writable by the user you can avoid creating the $writable_dir.
Of course you have to make sure that /home/$user is only accessable by $user.
_________________
...it's only Rock'n'Roll, but I like it!

[mark_alec]

Moved from Networking & Security to Documentation, Tips & Tricks.
_________________
www.gentoo.org.au || #gentoo-au

[m27315]

[Erlend]

I get,

[m27315]

hmmm, that sounds strange... Would you mind posting the output of these commands?

[Erlend]

[m27315]

What are the contents of the sftpuser's home dir:

[Erlend]

[m27315]

Just to make sure, would you post this result again:

[Erlend]

[m27315]

I used the above script, after bug fix. I used the sshd settings you posted. And, I also could not log in.

[m27315]

Try this:

[Erlend]

[m27315]

Great! Glad to help!

[thrashed]

hey dudes,

i configured the chroot scp service as mentioned above. first i ran into the permission issue. a good article about that --> http://www.tenshu.net/archives/2008/10/09/openssh-51-chrootdirectory-permissions-issue

i guess everything is configured ok, but when i try to login via winscp i get this error from winscp:

[m27315]

Hey thrashed,

Nothing jumps out at me, although several questions came to mind. Would you mind reporting all the relevant info, like I did in the above post:

https://forums.gentoo.org/viewtopic-p-5177319.html#5177319

This will help troubleshoot.

Also, I can't promise that I will be able to look at this soon. Maybe someone else will have time? Regardless, the above info will be needed, unless someone else recognizes a clear symptom of a known issue. I did not.

[Naib]

put it on the wiki!
_________________

[MarcusXP]

I managed to create users successfully and the permissions are working nicely (they can only write to the public folder and they are locked in the home folder).

I have an issue, though:
how do I set a limit for download/upload speed of the users I created?

[m27315]

[EstebanGonzales]

I cant seem to login in through scp with this script any ideas what the problem is.
Been trying to find a solution to this for days now

[m27315]

The problem could be anything. Please post relevant snippets from your log files, configs, shell transcripts, error messages, etc.. Read through the above posts to pick out the important pieces required to debug.