Download Securing Debian Manual

Chapter G. Chroot environment for SSH
152
• Configure /etc/security/chroot.conf so that the users you determine are chrooted to the directory you setup
previously. You might want to have independent directories for different users so that they will not be able to see
neither the whole system nor each other’s.
• Configure SSH: Depending on your OpenSSH version the chroot environment might work straight of the box or
not. Since 3.6.1p2 the do_pam_session() function is called after sshd has dropped privileges, since chroot() needs root
priviledges it will not work with Privilege separation on. In newer OpenSSH versions, however, the PAM code
has been modified and do_pam_session is called before dropping priviledges so it will work even with Privilege
separation is on. If you have to disable it modify /etc/ssh/sshd_config like this:
UsePrivilegeSeparation no
Notice that this will lower the security of your system since the OpenSSH server will then run as root user. This means
that if a remote attack is found against OpenSSH an attacker will get root privileges instead of sshd, thus compromising
the whole system. 4
If you don’t disable Privilege Separation you will need an /etc/passwd which includes the user’s UID inside the chroot for
Privilege Separation to work properly.
If you have Privilege Separation set to yes and your OpenSSH version does not behave properly you will need to disable it.
If you don’t, users that try to connect to your server and would be chrooted by this module will see this:
$ ssh -l user
user@server’s
Connection to
Connection to
server
password:
server closed by remote host.
server closed.
This is because the ssh daemon, which is running as ’sshd’, is not be able to make the chroot() system call. To disable
Privilege separation you have to modify the /etc/ssh/sshd_config configuration file as described above.
Notice that if any of the following is missing the users will not be able to logon to the chroot:
• The /proc filesystem needs to be mounted in the users’ chroot.
• The necessary /dev/pts/ devices need to exist. If the files are generated by your running kernel automatically then
you have to manually create them on the chroot’s /dev/.
• The user’s home directory has to exist in the chroot, otherwise the ssh daemon will not continue.
You can debug all these issues if you use the debug keyword in the /etc/pam.d/ssh PAM definition. If you encounter
issues you might find it useful to enable the debugging mode on the ssh client too.
Note: This information is also available (and maybe more up to date) in /usr/share/doc/libpam-chroot
/README.Debian.gz, please review it for updated information before taking the above steps.
G.1.2
Patching the ssh server
Debian’s sshd does not allow restriction of a user’s movement through the server, since it lacks the chroot function that the
commercial program sshd2 includes (using ’ChrootGroups’ or ’ChrootUsers’, see sshd2_config(5)). However, there is
a patch available to add this functionality available from ChrootSSH project (http://chrootssh.sourceforge.net)
(requested and available in Bug #139047 (http://bugs.debian.org/139047) in Debian). The patch may be included
in future releases of the OpenSSH package. Emmanuel Lacour has ssh deb packages for sarge with this feature. They are
available at http://debian.home-dn.net/sarge/ssh/. Notice that those might not be up to date so completing the
compilation step is recommended.
After applying the patch, modify /etc/passwd by changing the home path of the users (with the special /./ token):
joeuser:x:1099:1099:Joe Random User:/home/joe/./:/bin/bash
This will restrict both remote shell access, as well as remote copy through the ssh channel.
Make sure to have all the needed binaries and libraries in the chroot’ed path for users. These files should be owned by
root to avoid tampering by the user (so as to exit the chroot’ed jailed). A sample might include:
4 If
you are using a kernel that implements Mandatory Access Control (RSBAC/SElinux) you can avoid changing this configuration just by granting
the sshd user privileges to make the chroot() system call.