Chrooting SSHd

Ganhawk's Project Page (for other projects)

Download          Installation        Details       Contact me - ganhawk (at)

Background and Introduction:

I wanted to run SSHd

The Open SSH
daemon has its own security feature called previlage seperation and hence it is not designed to work with chroot. The developers argue the reason for SSH is to monitor the system remotely and chrooting it does not serve the purpose.  You can as well not run ssh. Actually, that exactly is what I did. I allow SSH only from the local lan. But what about the case when you want to run just a chrooted SFTP server ?

There is a patch by James Dennis called chrootssh. But this patch calls a chrooted shell when a paticular user logs in (the user must be marked in the /etc/passwd so that sshd can identify). You can setup a chroot with rssh (rssh is a shell that allows only sftp and not ssh) and use this patch to chroot the user to his directory. But the ssh you are running still runs as / and other users can login through this port. Granted, one can control the access in the sshd_config file, but still I felt it should be possible to just run sshd within chroot only for sftp.  If you are going to setup the chroot environment anyways, why not run the daemon itself under chroot.

This is the reason for my patch

Chroot Patch

Disclaimer:  I am not responsible for any security breech or any damage whatsoever due to this patch. Also this patch is not provided by the OpenBSD group and I am in no way connected with them.

Download patch for:         


tar -xzvf openssh-4.0p1.tar.gz

patch -p0 < /path/to/patch

make install


This patch adds another option ( -c ) to sshd. Use -c to tell sshd where the chroot jail is. Eg:

# /path/openssh-4.0p1/sshd -c /home/jail

This runs sshd Jailed to /home/jail


This patch runs the SSH
daemon itself chrooted to the Jail. The chroot is called only after the keys are loaded, hence you can store your private keys and sshd_config outside the chroot jail. Once the keys are loaded sshd runs chrooted. I think this is important because even if the attacker gets into the jail, he cannot get the keys without breaking chroot.

The user who logs in must be in ~jail/etc/passwd . Also the sftp-server must be inside the jail as ssh calls the sftp server only when the session is established.
The privilage seperation still exists, so make sure the ~jail/etc/passwd contains the user sshd. Also make sure you have the directory ~jail/var/empty. The main daemon runs chrooted to ~jail. The children are chrooted to ~jail/var/empty.

The jail can be customized as you wish. Also note that you need to build your jail with pts support, Building a chroot jail is beyond the scope of this document (which usually means that I am too lazy to type so look for it somewhere else ;). You can also look at JailKit for creating chroot jails. Also build your jails as thin as possible. The more number of files you have in your jail, the more you are vulnerable


chroot breaking out