View Single Post
Old 14th March 2009, 20:00
hrvbid hrvbid is offline
Junior Member
Join Date: Nov 2006
Posts: 13
Thanks: 9
Thanked 14 Times in 7 Posts
Default Chrooted environments with Ubuntu and IspConfig

Several howtos explain the steps to setup chrooted ssh environments with Ubuntu (and others) using together with ispConfig. I want to point about the logic of using chrooted ssh has changed rather drastic.
The good news is, openSSh V5 has builtin functionality for chroots. The more bad news are, ubuntu up to 8.04 uses openSSH V4 and only ubuntu 8.10 has openSSh V5.1.

With the said howtos, a patch was mentioned for openSSH to support chroot. The bad news are, the patch(es) for the different openSSH versions do no more exists at sourceforge and for some versions never had exist. Without the version dependent patch, chrooted ssh environments cannot be implemented with any openSSH V4. A bad circumstance now is: Ubuntu 8.04, thats an LTS, just only has openSSH V4 support.

To work with ssh chroots, the new logic of openSSh (V5) needs attention. The good messages are,
1st now chroot stuff is builtin (no more patching) and 2nd, that is really most easy to handle:

New declarations in sshd_config are implemented. I want to show those in a matter working
together with ispconfig (2.2.29) by adding only three lines at the end of the file:

Match Group web*
ChrootDirectory ~/
AllowTcpForwarding no
Nearly unbelievable, thats all. Match Group allows wildcards, while ChrootDirectory does not.
The example shown covers what ispConfig performs when new users (and groups) become created.
The 2nd line is most simple code without any need of wildcards and directs the user to his
(chrooted!) homedir that we know with ispconfig has site/group association. As usual in any
linux, the users have their homedir declared in passwd, and ChrootDirectory obviously refers
to by using ~/ with success.

That's really all?
No, we have to work out the past. Remember, ispConfig supports chroot with the specification


in that, as far I know, causes
1st, new system user definitions with the magic /./ in the homedir string, and
2nd, prepares the chrooted environment for the new user by copying some files and libraries
in the cage by a script.
The 1st item now is obsolete. The magic /./ is no longer needed, does not have to be used anymore
and ssh complains about an invalid path string is such case. That means, for all just existing
users managed by ispConfig, the central passwd should be adjusted by removing all magics /./
from each line. Thus, if ispConfig is requested to regard chroot ssh, the creation of the
new user should no more have the magic.
The 2nd action is just valid as in the past and no changes are required.
What else?
The users homedir always needs ownership root:root (has to change) and chmod 755 (as is).
And, the ssh server requires restart, of course, after the changes made.

Implementing ssh chroot is as easy as never before. With Ubuntu, only 8.10 supports openSSH V5.
But the new logic shows where to road leads to. IspConfig some day needs some adjustment, but
that can wait until the majority of systems (also beyond Ubuntu) are on the openSSH V5 drive.
Up the then, some manual work with the ispconfiged users is required for the admins, but that
is a minor impact against the perspective, to have a system very well adjusted to the future,
like openSsh, like Ubuntu, like last not least ispConfig.

Btw, having ssh chroot also just enables SFTP (but not FTPS). Simply add or change the line
Subsystem sftp internal-sftp
in sshd_config. Adding onother line above Match Group with
ForceCommand internal-sftp
allows the users to have sftp (with winscp, with filezilla etc), but no shell access. That
most powerfull means, you can kick off any (unsecure) ftp server from your system. If you want :-)
Reply With Quote
Sponsored Links