Put your OpenSSH server in SSHjail

Jailing is a mechanism to virtually change a system’s root directory. By employing this method, administrators can isolate services so that they cannot access the real filesystem structure. You should run unsecured and sensitive network services in a chroot jail, because if a hacker can break into a vulnerable service he could exploit your whole system. If a service is jailed, the intruder will be able to see only what you want him to see — that is, nothing useful. Some of the most frequent targets of attack, which therefore should be jailed, are BIND, Apache, FTP, and SSH. SSHjail is a patch for the OpenSSH daemon. It modifies two OpenSSH files (session.c and version.h) and allows you to jail your SSH service without any need for SSH reconfiguration.

To use SSHjail you need the OpenSSH source package, the SSHjail patch, and some development tools like patch and make. You also need the OpenSSL and Zlib development libraries installed in order to compile the patched SSH daemon. I’ve successfully installed SSHjail on CentOS 4.2 and Fedora 6 distribution; the instructions may be a bit different for your Linux flavor, but you’ll get the idea.

First, download the OpenSSH source and SSHjail patch. Unpack each and apply the patch. For instance, if you’ve installed the OpenSSH daemon version 4.5p1 in /usr/local folder:


~# cd /usr/local
~# tar xvfz openssh-4.5p1.tar.gz
~# patch -p0

After a successful patch, run the configuration script:


~# cd openssh-4.5p1
~# ./configure


At this point, if you get an error saying that your Zlib libraries are too old and are a potential security risk, you can bypass the error by using the following parameter with the configure command:


~# ./configure --without-zlib-version-check


The final step is to make and install the binaries:


~# make && make install


The binaries will be installed under the /usr/local folder, and the new sshd binary will be in /usr/local/sbin/sshd.

Before you can start the new daemon, you need to configure the following a few things. Create an /etc/sshjail.conf file, in which you define all users that will be jailed. Here is my example:


chroot=/public/jail1
users=anze,dasa,kimy,pablo
chroot=/public/jail2
users=@testers,raul


Here I’ve made two jails — jail1 and jail2. You can have as many jails as you like, but usually you need only one. The first line in the config file defines what will be the new root for jailed users. The second line defines the users that will be jailed. The example for the second jail2 group is the same, but I’ve used @group_name instead of naming all users that belong to the group testers. You can define as many users and groups as you like, separating them with commas.

Once you have the definitions ready, you need to set up a chroot environment for the users. This manual offers many details about the process.

I set up my chroot environment under the /public folder, where I created jail1 and jail2 folders for my users. In these folders (among the required bin and lib folders) I have a home folder where all the jailed users’ home folders are stored (see figure). The user folders in the chroot environment are basically copies of home folders from the standard /home location, with the exact same permissions. You also need to create bin and lib folders in the chroot environment and place the binaries that you want users to be able to access there (see the chroot environment manual for more info).

Finally, in the /etc/passwd file, you need to change the home folder path for all users that you’re jailing. For instance, in my case, let’s see what needs to be changed in /etc/passwd file for user pablo. The original line in /etc/passwd for the user pablo looks like this:


pablo:x:501:501::/home/pablo:/bin/bash


Pablo has his home folder located in the standard /home/pablo location. Since I am jailing the user pablo in the chroot environment, I change the home folder path to this:


pablo:x:501:501::/public/jail1/home/pablo:/bin/bash


At this point the configuration is done. All you need to do now is run the patched sshd daemon. To use the new daemon, you first need to stop running your old sshd binary (usually located in /usr/sbin/sshd) and make sure the new binary is run at every boot. Either replace the path to sshd file in /etc/rc.d/sshd script file or put the path to sshd in your /etc/rc.local file. Note that you don’t need to run the sshd daemon with the start parameter anymore.

Test

If you set up everything correctly, your restricted users should now be able to log in to your SSH server, and the environment should look something like this:


anze@mac:~$ ssh pablo@srv1.example.com
pablo@srv1.example.com's password:
Last login: Tue Apr 10 17:39:42 2007 from mac.example.com
-bash-3.00$ pwd
/home/pablo
-bash-3.00$ ls /
bin home lib


As you can see, user pablo will feel right at home (note the /home/pablo path). But as you can see, if I list the content of the root filesystem, I’ll only see what I’ve created in the actual /public/jail1 folder, meaning that user pablo is chrooted and can’t access any folders below the virtual root.

The most common error that you might get is this:


anze@mac:~$ ssh pablo@srv1.example.com
pablo@srv1.example.com's password:
Last login: Tue Apr 10 17:48:25 2007 from mac.example.com
/bin/bash: No such file or directory
Connection to srv1.example.com closed.


This means that you didn’t set up the chroot environment correctly — the bin folder cannot be found or there is no bash command in that folder.

There are some alternatives to SSHjail, such as using the PAM module map-chroot or a different patch named chrootssh. But I like SSHjail; author Gon&#199alo Silva really put effort into making this patch transparent to other running services on the system and eliminating the need to modify the OpenSSH config file in order for SSHjail to work.