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 $go_info["server"]["ssh_chroot"]=1; in config.inc.php 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. Conclusion: 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. Hilmar 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
Can You Help Me Hello. Your post has got me one step closer but not there yet. What exactly do I have to do to enable chroot ssh with ispconfig? Can you write the steps out in easy to understand order? Thanks. I have ubuntu server 8.10 with the latest openssh-server. I'm looking forward to getting this to work. thank again.
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 web20_u2:x:10020:10020:u2:/var/www/web20/./:/bin/bash That action is obsolete with the new openSsh logic. Instead, a normal home path for the new user has to set, like web20_u2:x:10020:10020:u2:/var/www/web20:/bin/bash 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: root:x:0:0:root:/root:/bin/bash www-data:x:33:33:www-data:/var/www:/bin/sh web20_u2:x:10020:10020:u2:/var/www/web20:/bin/bash 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 /root/ispconfig/scripts/shell/create_chroot_env.sh 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.
Thanks Thanks HRVBID! This makes things pretty clear. If I have trouble I'll ask more. I think I will give ispconfig 3 a spin since the stable version just came out. Later...
Thanks. Indeed this is working fine (I've implemented it on Ubuntu server 9.10 with ISPConfig 2.2.23). However, I have noticed that the /./ thing is somehow 'returning' to the /etc/passwd (after I have manually removed it). I suspect that it has to do with the update mechanism of the ISPConfig. Do you know the reason for that? Is there some kind of a master file for the /etc/passwd , like for example the named.bind.master? Thanks, YBZ
