NSLU2-Linux
view · edit · print · history

HowTo.ChrootJailForSFTP History

Hide minor edits - Show changes to markup

June 23, 2007, at 09:16 PM by marceln -- Added reference to scponly
Changed lines 11-13 from:
  • The use of scponly which is an other approach (See scponly).
to:
  • The use of scponly which is an other simple approach (See scponly).
June 23, 2007, at 09:15 PM by marceln -- Added reference to scponly
Changed lines 11-13 from:
  • The use of scponly which is an other approach (See Any experience with chroot jail for SFTP with unslung6?).
to:
  • The use of scponly which is an other approach (See scponly).
June 23, 2007, at 09:14 PM by marceln -- Added reference to scponly
Changed lines 11-13 from:
  • The use of scponly which is an other approach (See ).
to:
  • The use of scponly which is an other approach (See Any experience with chroot jail for SFTP with unslung6?).
June 23, 2007, at 09:13 PM by marceln -- Added reference to scponly
Changed lines 11-12 from:
  • The use of scponly which is an other approach (See Any experience with chroot jail for SFTP with unslung6?).
to:
  • The use of scponly which is an other approach (See ).
March 09, 2007, at 10:15 PM by marceln -- Revormated script to make it smaller
Changed lines 11-12 from:
  • The use of scponly which is an other approach (See Any experience with chroot jail for SFTP with unslung6?)
to:
  • The use of scponly which is an other approach (See Any experience with chroot jail for SFTP with unslung6?).
Changed lines 116-117 from:
        echo "Interactive login not allowed!"                  # comment out this line (and the next line) when you want to allow an interactive login
to:
        echo "Interactive login not allowed!"                  
        # comment out this line (and the next line) when you want to allow an interactive login
Changed lines 119-120 from:
        # sudo /usr/sbin/chroot /home/$USER /bin/su - $USER    # uncomment this line when you want to allow an interactive login
to:
        # sudo /usr/sbin/chroot /home/$USER /bin/su - $USER
        # uncomment this line when you want to allow an interactive login
March 09, 2007, at 10:13 PM by marceln -- Added scponly
Changed lines 9-14 from:

This page does not describe how to switch from Dropbear to OpenSSH, for this see SwapFromDropbearToOpenSSH. This page does not describe to enable OpenSSH for remote access, for this see UseOpenSSHForRemoteAccess.

The use of scponly which is an other approach

See Any experience with chroot jail for SFTP with unslung6?

to:
  • This page does not describe how to switch from Dropbear to OpenSSH, for this see SwapFromDropbearToOpenSSH.
  • This page does not describe to enable OpenSSH for remote access, for this see UseOpenSSHForRemoteAccess.
  • The use of scponly which is an other approach (See Any experience with chroot jail for SFTP with unslung6?)
March 09, 2007, at 10:12 PM by marceln -- Added scponly
Added lines 12-14:

The use of scponly which is an other approach

See Any experience with chroot jail for SFTP with unslung6?

October 22, 2006, at 07:12 PM by marty_k71 -- Update the fake shell code to block interactive SSH logins.
Changed lines 115-117 from:
        sudo /usr/sbin/chroot /home/$USER /bin/su - $USER 
to:
        echo "Interactive login not allowed!"                  # comment out this line (and the next line) when you want to allow an interactive login
        exit 1
        # sudo /usr/sbin/chroot /home/$USER /bin/su - $USER    # uncomment this line when you want to allow an interactive login
Changed lines 121-122 from:

TODO - I will do some optimization here. I do not want users to get an interactive shell. Eventhough it has limited functionality. I will add some code to terminate when an attempt is made to start an interactive shell.

to:

This fake shell will terminate with an error message in case an interative login is started. So, this fake shell only allows the SFTP connection. See the comment in the false-branch of the if-then-else construction what to di in case you do want to enable interactive logins.

October 16, 2006, at 10:36 AM by marty_k71 -- Added the weblink
Changed lines 103-115 from:

[@#!/bin/bash
if [ "$1" = "-c" ]; then
i=0;
PARAMS="";
for param in $*; do
if [ $i -gt 0 ]; then
PARAMS="$PARAMS $param";
fi
let i++;
done;
sudo /usr/sbin/chroot /home/$USER /bin/su - $USER -c "$PARAMS"
else
sudo /usr/sbin/chroot /home/$USER /bin/su - $USER \\

to:

[@#!/bin/bash if [ "$1" = "-c" ]; then

        i=0; 
        PARAMS=""; 
        for param in $*; do 
                if [ $i -gt 0 ]; then 
                        PARAMS="$PARAMS $param"; 
                fi 
                let i++; 
        done; 
        sudo /usr/sbin/chroot /home/$USER /bin/su - $USER -c "$PARAMS" 

else

        sudo /usr/sbin/chroot /home/$USER /bin/su - $USER 
Changed lines 140-143 from:

For the major part this solution is based upon work by Tony J. White and Brian Rhodes found at This website descrbing the chroot login howto.

to:

For the major part this solution is based upon work by Tony J. White and Brian Rhodes found at http://www.tjw.org/chroot-login-HOWTO .

October 16, 2006, at 10:23 AM by marty_k71 --
Changed lines 140-143 from:

For the major part this solution is based upon work by ??? found at ???? .

to:

For the major part this solution is based upon work by Tony J. White and Brian Rhodes found at This website descrbing the chroot login howto.

October 16, 2006, at 10:16 AM by marty_k71 -- Formatting.... I should have used the sandbox first...
Changed lines 6-7 from:

There is a patch around that adds chroot functionality to the OpenSSH? server directly. But there is no package for this OpenSSH? patch available at our Slug. I didn't want to go throug the hassle to compile it myself. So I looked for another solution. It is possible to implement a chroot jail using existing packages and a little script. This is what this page describes.

to:

There is a patch around that adds chroot functionality to the OpenSSH server directly. But there is no package for this OpenSSH patch available at our Slug. I didn't want to go throug the hassle to compile it myself. So I looked for another solution. It is possible to implement a chroot jail using existing packages and a little script. This is what this page describes.

Changed lines 9-11 from:

This page does not describe how to switch from Dropbear to OpenSSH?, for this see SwapFromDropbearToOpenSSH. This page does not describe to enable OpenSSH? for remote access, for this see UseOpenSSHForRemoteAccess.

to:

This page does not describe how to switch from Dropbear to OpenSSH, for this see SwapFromDropbearToOpenSSH. This page does not describe to enable OpenSSH for remote access, for this see UseOpenSSHForRemoteAccess.

Changed lines 19-21 from:
  • OpenSSH? (ipkg install openssh)
  • OpenSSH? sftp server (ipkg install openssh-sftp)
to:
  • OpenSSH (ipkg install openssh)
  • OpenSSH sftp server (ipkg install openssh-sftp)
Changed line 47 from:

Here you must create two devices required for OpenSSH?.Execute the next commands:

to:

Here you must create two devices required for OpenSSH. Execute the next commands:

Changed line 103 from:

[=#!/bin/bash \\

to:

[@#!/bin/bash \\

Changed line 116 from:

fi;=]

to:

fi;@]

October 16, 2006, at 10:12 AM by marty_k71 -- Added todo\'s, corrected typo\'s and formatting
Changed lines 4-7 from:

Why a chroot jail? Firstly for security. Secondly the user can access only a limited part of the filesystem. Of course you can do quite a lot with carefully defining and setting permissions and ownership. But still quite a lof of the file system would be visible. Which most likley you do not want. At least I do not want it at my Slug. I want to lock the sftp user it its home directory with very limited functionality. An interactive SSH session is not required. The account is intended to share files between friends. This page describes how to apply a chroot jail to an existing OpenSSH? installation at OpenSlug. It is very generic, so I expect it will work at other firmware versions as well.

There is a patch around that adds chroot functionality to the OpenSSH? server directly. But there is not package for this OpenSSH? patch available at our Slug. I didn't want to go throug the hassle to compile it myself. So I looked for another solution. It is possible to implement a chroot jail using existing packages and a little script. This is what this page describes.

to:

Why a chroot jail? Firstly for security. Secondly the user can access only a limited part of the filesystem. Of course you can do quite a lot with carefully defining and setting permissions and ownership. But still quite a lot of the file system would be visible. Which most likley you do not want. At least I do not want it at my Slug. I want to lock the sftp user it its home directory with very limited functionality. An interactive SSH session is not required. The account is intended to share files between friends. This page describes how to setup a chroot jail at OpenSlug. It is very generic, so I expect it will work at other firmware versions as well.

There is a patch around that adds chroot functionality to the OpenSSH? server directly. But there is no package for this OpenSSH? patch available at our Slug. I didn't want to go throug the hassle to compile it myself. So I looked for another solution. It is possible to implement a chroot jail using existing packages and a little script. This is what this page describes.

Changed lines 13-14 from:

This page assumes that you use public key authentication for logging in to the SSH server. So carefully follow the UseOpenSSHForRemoteAccess]]. Also the user account you want to use has been setup already.

to:

This page assumes that you use public key authentication for logging in to the SSH server. So carefully follow the UseOpenSSHForRemoteAccess. Also the user account you want to use has been setup already.

Changed lines 81-82 from:
to:

TODO - I have to admit, I need to do some optimization here. Firstly the symlinks in /lib are copied as real files. Secondly I did not check, which are actually needed. I will do that and then update this page accordingly.

Changed lines 103-116 from:

@#!/bin/bash if [ "$1" = "-c" ]; then

        i=0;
        PARAMS="";
        for param in $*; do
                if [ $i -gt 0 ]; then
                        PARAMS="$PARAMS $param";
                fi
                let i++;
        done;
        sudo /usr/sbin/chroot /home/$USER /bin/su - $USER -c "$PARAMS"

else

        sudo /usr/sbin/chroot /home/$USER /bin/su - $USER

fi;

to:

#!/bin/bash \\ if [ "$1" = "-c" ]; then \\ i=0; \\ PARAMS=""; \\ for param in $*; do \\ if [ $i -gt 0 ]; then \\ PARAMS="$PARAMS $param"; \\ fi \\ let i++; \\ done; \\ sudo /usr/sbin/chroot /home/$USER /bin/su - $USER -c "$PARAMS" \\ else \\ sudo /usr/sbin/chroot /home/$USER /bin/su - $USER \\ fi;

Changed lines 118-119 from:

make sure you set the permissions of this file to 755.

to:

make sure you set the permissions of this file to 755.
TODO - I will do some optimization here. I do not want users to get an interactive shell. Eventhough it has limited functionality. I will add some code to terminate when an attempt is made to start an interactive shell.

Deleted line 133:
Changed lines 136-138 from:
to:

Orginal home directoy

I changed the permissions and ownership of the orginal home directory. Now root:root owns /home/public. Permissions have been set to 755. This prevents the user to write anywhere but the /home/public/public (when in the chroot jail /public) directory.

Acknowledgements

For the major part this solution is based upon work by ??? found at ???? .

October 15, 2006, at 08:05 PM by marty_k71 -- Last formatting change for today
Changed line 43 from:

ln -s tinylogin su \\

to:

ln -s tinylogin su

Added line 75:

Simply copy everything from the real /lib to /home/public/lib:

Deleted line 77:

Simply copy everything from the real /lib to /home/public/lib: \\

October 15, 2006, at 08:02 PM by marty_k71 -- Again some formatting updates
Changed line 8 from:

What is __not__ described here

to:

What is not described here

Changed lines 39-43 from:

cd /home/public/bin cp /bin/busybox . cp /bin/tinylogin . ln -s busybox sh ln -s tinylogin su

to:

cd /home/public/bin
cp /bin/busybox .
cp /bin/tinylogin .
ln -s busybox sh
ln -s tinylogin su \\

Changed lines 50-51 from:

cd /home/public/dev mknod -m 0666 tty c 5 0

to:

cd /home/public/dev
mknod -m 0666 tty c 5 0 \\

Changed line 59 from:

root:*:0:

to:

root:*:0: \\

Changed line 68 from:

root:*:0:0:root:/:/bin/sh

to:

root:*:0:0:root:/:/bin/sh \\

Changed lines 77-78 from:

Simply copy everything from the real /lib to /home/public/lib: cd /home/public/lib

to:

Simply copy everything from the real /lib to /home/public/lib:
cd /home/public/lib \\

Changed line 102 from:
  1. !/bin/bash
to:

@#!/bin/bash

October 15, 2006, at 07:59 PM by marty_k71 -- Corrected some wrong formatting
Changed lines 53-54 from:

(:tableend:

to:

(:tableend:)

Changed line 102 from:
  1. !/bin/bash
to:
  1. !/bin/bash
October 15, 2006, at 07:55 PM by marty_k71 -- First version of a document that describes the implementation of a chroot jail at OpenSlug
Added lines 1-137:

This howto covers the setup of a chroot jail for an account that is intended to be accessed via sftp.

Introduction

Why a chroot jail? Firstly for security. Secondly the user can access only a limited part of the filesystem. Of course you can do quite a lot with carefully defining and setting permissions and ownership. But still quite a lof of the file system would be visible. Which most likley you do not want. At least I do not want it at my Slug. I want to lock the sftp user it its home directory with very limited functionality. An interactive SSH session is not required. The account is intended to share files between friends. This page describes how to apply a chroot jail to an existing OpenSSH? installation at OpenSlug. It is very generic, so I expect it will work at other firmware versions as well.

There is a patch around that adds chroot functionality to the OpenSSH? server directly. But there is not package for this OpenSSH? patch available at our Slug. I didn't want to go throug the hassle to compile it myself. So I looked for another solution. It is possible to implement a chroot jail using existing packages and a little script. This is what this page describes.

What is __not__ described here

This page does not describe how to switch from Dropbear to OpenSSH?, for this see SwapFromDropbearToOpenSSH. This page does not describe to enable OpenSSH? for remote access, for this see UseOpenSSHForRemoteAccess.

Assumption

This page assumes that you use public key authentication for logging in to the SSH server. So carefully follow the UseOpenSSHForRemoteAccess]]. Also the user account you want to use has been setup already.

Required packages

The next packages must be installed to make this all work. If not available at your Slug, then install them.

  • bash (ipkg install bash)
  • sudo (ipkg install sudo)
  • OpenSSH? (ipkg install openssh)
  • OpenSSH? sftp server (ipkg install openssh-sftp)

Account setup

Setup an account for sftp access. For this example the username will be public and the groupname will be remote. The home directory is /home/public. In this directory, create the next directories:

  • .ssh
  • bin
  • dev
  • etc
  • lib
  • usr
  • usr/lib
  • usr/libexec
  • public

The directories .ssh and public should be owner by public:remote. Others by root:root. Permissions must be 755 for all except .ssh, this must be 700. The .ssh directory should contain the authorized_keys file for public key authentication. This is still normal, the other directories contain copies from specific files from the real file system. All commands in the next sub sections must be executed as root.

Directory bin

(:table border=0 width=100% bgcolor=#eeffee:) (:cell:) cd /home/public/bin cp /bin/busybox . cp /bin/tinylogin . ln -s busybox sh ln -s tinylogin su (:tableend:)

Directory dev

Here you must create two devices required for OpenSSH?.Execute the next commands: (:table border=0 width=100% bgcolor=#eeffee:) (:cell:) cd /home/public/dev mknod -m 0666 tty c 5 0 mknod -m 0644 urandom c 1 9 (:tableend:

Directory etc

Create a group and passwd file here. The content of the group file should be: (:table border=0 width=100% bgcolor=#eeffee:) (:cell:) root:*:0: remote:x:64006: (:tableend:)

Assuming that 64006 is the group id of your remote group the real /etc/group. Adjust this to your own needs. You might want to add other group names that might put files/directories in the account when in use.

The content of the passwd file should be: (:table border=0 width=100% bgcolor=#eeffee:) (:cell:) root:*:0:0:root:/:/bin/sh public:*:507:64006:sftp account,,,:/public:/bin/sh (:tableend:)

Again, assuming that 64006 is the group id of your remote group in both /etc/group and /home/public/etc/group. And that 507 is user id of public in the real /etc/passwd as well. You might want to add other user names that might put files/directories in the account when in use.

Directory lib

(:table border=0 width=100% bgcolor=#eeffee:) (:cell:) Simply copy everything from the real /lib to /home/public/lib: cd /home/public/lib cp -R /lib/* . (:tableend:)

Directory public

This one remains empty. This will contain the actual files when the account is in use. This will be the home directory of the chroot-ed user.

Directory usr

This directory only contains the lib and libexec subdirectories.

Directory usr/lib

This directory contains the next libraries (copied from /usr/lib):

  • libcrypto.so.0.9.7
  • libz.so.1

Directory usr/libexec

This directory contains actual sftp server (copied from /usr/libexec):

  • sftp-server

Final settings

Fake shell

Now you must create a 'fake shell' This shell will be started when the public user log on the Slug. This fake shell is actually a script, which performs the change root actual. As chroot can be executed by root only, we must use sudo to be able to make this work. Create a new shell script and name it /bin/chrootshell. Its contents must be: (:table border=0 width=100% bgcolor=#eeffee:) (:cell:)

  1. !/bin/bash

if [ "$1" = "-c" ]; then

        i=0;
        PARAMS="";
        for param in $*; do
                if [ $i -gt 0 ]; then
                        PARAMS="$PARAMS $param";
                fi
                let i++;
        done;
        sudo /usr/sbin/chroot /home/$USER /bin/su - $USER -c "$PARAMS"

else

        sudo /usr/sbin/chroot /home/$USER /bin/su - $USER

fi; (:tableend:) make sure you set the permissions of this file to 755.

Setup sudo

Edit the /etc/sudoers' using visudo. Add the next line at the end of the sudoers file: (:table border=0 width=100% bgcolor=#eeffee:) (:cell:) public ALL= NOPASSWD: /usr/sbin/chroot /home/public /bin/su - public* (:tableend:)

Setup the real public account

You did already setup a real system account named public. This must be adapted slightly. Edit the real /etc/passwd file and Make sure it has the next content for the line that defines the public user: (:table border=0 width=100% bgcolor=#eeffee:) (:cell:) public:x:507:64006:sftp user,,,:/home/public:/bin/chrootshell (:tableend:)

Of course the clue is in the entry that defines the shell for this public account. Which actually is the script that we just have created.

view · edit · print · history · Last edited by marceln.
Based on work by marceln and marty_k71.
Originally by marty_k71.
Page last modified on June 23, 2007, at 09:16 PM