Thanks for the reply. I think, it's too early to write a howto for chroot ssh for ispconfig
because some items are yet not without inconsistences. But I will try to explain some steps here more in detail:
An elementary property is in the file /home/admispconfig/ispconfig/lib/config.inc.php with
a coding around line #106:
$go_info["server"]["ssh_chroot"] = 1;
that obviously tells ispconfig to regard a chrooted environment when creating new webs with users. That causes, as far as I can see, two events:
1.) The user is created in the /etc/passwd file, but with the magic home path allocation
containing a '/./' where the path should split for the chroot, like
That action is obsolete with the new openSsh logic. Instead, a normal home path for the new user has to set, like
This change, at the moment, has to perform manually. Sure, you will need root/sudo permissions to handle the central /etc/passwd file. And, there is a 2nd passwd file within the jail of the new user in /var/www/web20/etc/passwd with a short extract from the central passwd file:
That complete 3-liner only contains the home user, the web servers account and the root user.
To manually remove the magic in the home path, both passwd files require modifications. In future, sure that should be the mission of ispconfig to adjust the right coding.
2.) To build a chrooted environment, ispconfig runs a script to create and copy the elementary directories and files for the new user. It's clear, the user will not have any access to the real root (/) filesystem, he assumes that was follows beyond the real /var/www/web20/ is the root (/). That's the way the jail functions. The user will need a lot of executable files, like an editor, and much more, to perform some system tasks he should be granted. In case nothing would placed in the jail, the user would not be able to just login. The ispconfig script's mission is to prepare the environment for the new user and that is placed in
and should be treated as a general template to build the environment. At this point, regard, it's the full responsibility of a central admin to select every item for the new user. I think, the selections have to be made very sensitive depending on what the new user is granted to do. Note, some executable binaries (not included in the template) may be misused to break out of the jail. Indeep system knowledge is required, to include some functionality or always exclude them. (See the several 'chroot' discussions googled). But a lot of binaries are often very needed, like wget, like tar and a lot stuff more. Thus, it's a decision about a whole system environment for the new user. In the mentioned script, you can see the general basics about such an environmnet. For myself, I use an own script with different environments, depending on the users.
And 3.) The permissions need adjustment. The root of the users web requires
(/var/www/)web20 rwxr-x-r-x root:root
The subdirs within, like 'bin', 'lib' etc. should urgend also owned by root with very limited permissions to the user (to prevent the users idea to place some binaries in to break out of the jail), while the subdir 'web' is owned by the user.
Conclusion up to now: ispconfig supports very many systems environments with different items, also with different chrooting concepts, where the new one of openSsh is only one. I think, it's time for the next future to round up that all. But that's more then an easy quick task. Up the then, all admins of ispconfig have to follow their own concepts to be stable for the own system.
Sorry, that I cannot tell the steps to perform easier to unterstand. But chrooting is a well security feature, that wants to be handled with care. Thus, I shy to write only a cookbook of how to do.
One tip, the logs will tell you mistakes made in any case, like /var/log/auth.log
Please feel free to continue asking about details going wrong, but I can answer only from time to time.
Last edited by hrvbid; 28th March 2009 at 13:57.