Linux

Chroot users with OpenSSH: An easier way to confine users to their home directories

With the release of OpenSSH 4.9p1, you no longer have to rely on third-party hacks or complicated chroot setups to confine users to their home directories or give them access to SFTP services. Vincent Danen tells you how to take advantage of this new addition to OpenSSH.

With previous versions of OpenSSH, the only way to confine users to their home directories was with third-party hacks or elaborate chroot setups. The recently-released 4.9p1 release of OpenSSH, however, provides the ability to chroot users without the use of third-party add-ons; a welcome addition to this powerful tool.

As well, providing SFTP services that restricts users to their home directory is much simpler now.

To begin, ensure you have OpenSSH 4.9p1 or newer installed. Then edit /etc/ssh/sshd_config (/etc/sshd_config on some distributions) and set the following options:

Subsystem     sftp   internal-sftp
Match Group sftp
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

Ensure the "Match" directive is at the end of the file. This tells OpenSSH that all users in the sftp group are to be chrooted to their home directory (which %h represents in the ChrootDirectory command), forces the use of the internal-sftp helper, and disables TCP port forwarding. The Subsystem command previously enabled is required to enable the use of the SFTP subsystem. This can either be a path to the sftp-server helper, or the internal-sftp, but for the purpose of chrooting, the internal-sftp command works better and doesn't require a shell or libraries installed in the chroot.

For any users that you wish to chroot, add them to the sftp group by using:

# usermod -G sftp joe
# usermod -s /bin/false joe
# chown root:root /home/joe
# chmod 0755 /home/joe

The usermod command above will add user joe to the sftp group and set their shell to /bin/false so they absolutely cannot ever get shell access. The chown and chmod commands will set the required permissions for the directory. With these permissions set, the user will be allowed to upload and download files, but cannot create directories or files in the root directory. In other words, if this is used for Web hosting, ensure that a subdirectory in the root directory, such as /home/joe/public_html/ is available and owned by the user; this way they can write to and create directories in /home/joe/public_html/, but cannot make changes to the root directory (/home/joe), itself.

Chrooting shell accounts is a little more complicated as it requires that certain device files and a shell be available in the user's home directory. The following commands will set up a very basic chroot system on Mandriva Linux:

# mkdir /chroot
# cd /chroot
# mkdir {bin,dev,lib}
# cp -p /bin/bash bin/
# cp -p /lib/{ld-linux.so.2,libc.so.6,libdl.so.2,libtermcap.so.2} lib/
# mknod dev/null c 1 3
# mknod dev/zero c 1 5
# chmod 0666 dev/{null,zero}
# mkdir -p /chroot/home/joe

With the above, user joe can ssh in and will be restricted to the chroot. Unfortunately, this doesn't do much, but it gives you an idea of how it can be set up. Depending on what you want to provide, you will need to install additional libraries and binaries. One idea might be to have a chroot setup that is a minimal distribution install. For instance, with Mandriva you can install a second copy of the operating system using urpmi in the /chroot directory. All authentication information is taken from the host, so there is no need to create and maintain user passwords inside the chroot, and this would allow for another degree of separation from the main/host operating system to where users are permitted access, effectively jailing them inside a second OS with limited tools and functionality.

Of the two, chrooted SFTP is the easiest to set up and maintain and is likely sufficient for most remote access use.

Get the PDF version of this tip.

About

Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.

11 comments
Christian De Bellefeuille
Christian De Bellefeuille

I can access & download files, and no shell, but i can't upload anything.   I'm using Ubuntu 12.04 LTS.  If you have any idea, i would appreciate your help.

infam0us1
infam0us1

does this work with slackware 13.37 ?? this seems very simple/cut and dry.... great way to confine users.... just hope i can make it work with on slackware box

jack6666
jack6666

... this little post and was very much astonished as to how well it answered the very problems I was experiencing. Just wanted to relay a warm and heartfelt thanks. Driveway Lights|Outdoor String Lights

HowdyMedia
HowdyMedia

Doing this with crash SSH if you don't have the right version of OpenSSH installed. If you can't walk over to the server, then you will be locked out and need to have your host provider manually fix the issue at the server itself. If you have *any doubts*, temporarily enable Telnet so that you can have a backdoor in to fix your sshd_config file if needed. I followed advice which led people to believe that you can have an old version, say 3.9 on CentOS, that if your server does regular updates your version has been backported and all necessary patches have been applied. DO NOT RELY ON THIS! Manually install the update if your version is not up to date.

leluckimsach
leluckimsach

Subsystem sftp internal-sftp Match Group sftp ChrootDirectory %h ForceCommand internal-sftp AllowTcpForwarding no >>> Only chroot for SFTP, but we are using SSH services and bash shell, what do we configuration for SSH and using command at home's bash shell

Mikeo1313
Mikeo1313

Can you recommend vpn software with a management gui to allow & disallow select folder access & priviledges per user? (windows or linux, doesn't matter)thanks

eldergabriel
eldergabriel

You've done it again, man. I've always been a huge fan of openssh, and I really like interesting articles such as this. What would you think of putting busybox (y'know, the statically-linked command-line shell-in-a-shell swiss army knife) inside the chroot environment, in place of all the other stuff? This would save time, but I suppose if this is a setup that is intended to be replicated repeatedly, you would want to automate that with a shell script or something, anyway. Just a thought. What think the rest of you?

techrepublic@
techrepublic@

It will save disk space and reduce maintenance work.

cflange
cflange

Excellent article. It's a gem, rich and concise, that teaches me a new thing every line. And it is such a useful idea, I know I will come back to it many times in the future. Thanks!

Neon Samurai
Neon Samurai

My first instinct is that it would set a minimum level of functionality too high. If a user doesn't need, tar, ls, cd or some other specific function then I'd leave it out of the chroot environment (ls and cd are stretching it but it's an example). With Busybox, I think you'd need to recompile without the unneeded functions else every user gets more than they need by default. It may break least privilege by forcing you to open up more than is required by the user.