Hi, the passwd line looks like: Code: web27_grrr:x:10040:10027:grrr:/var/www/web27/./:/bin/false I followed Falkos instructions to compile a new openssh server (only point 2 of the instructions, but nothing more on my Debian Etch, because I was too lazy for zlib compiling and creating the folders in /home/chroot/) and I set the ISPconfig 2.2.23 config.inc.php value to $go_info["server"]["ssh_chroot"] = 1; as necessary. All seems to work correctly, but all new webs get the cage folders like /usr, /etc, /bin. /lib, /var copied to /var/www/web27_grrr. What's my mistake? Or is this intended? Thanks for the help.
That's the correct behaviour. The /home/chroot from the tutorial is just an example; ISPConfig chroots the users to the web directory they belong to.
Sorry. my question was not clear enough. Another try: if I create a new web then the bin, usr, etc, var folders are copied to the webs root, although SSH is not and was never enabled. How can I avoid this?
There are 2 functions inside /root/ispconfig/scripts/lib/config.lib.php: user_insert() and user_update() which, at their very end, call the script for creating the chroot folders: PHP: if($go_info["server"]["ssh_chroot"]) { exec("/root/ispconfig/scripts/shell/create_chroot_env.sh $user_username"); } and indeed this is called for every user when ssh_chroot for the server is enabled, regardless if the web or even the user has chroot access. This is consuming customers webspace (consider mounts of user accounts) and is irritating also. Changing these lines (for ISPconfig 2.2.23 at line number 767 and 941 of config.lib.php) to: PHP: if($go_info["server"]["ssh_chroot"] == 1 && $user["user_shell"] && $web["web_shell"]) { exec("/root/ispconfig/scripts/shell/create_chroot_env.sh $user_username"); } works as expected: no SSH folders will be created on new webs or users with non-checked SSH. Falko, do you think there is sth. missing in this solution that could make side effects? Nevertheless this does not delete the chroot folders for users if SSH in the admin panel is unchecked again, for both the user or the web. The chroot folders will, once enabled, remain.
I am just wondering why this info: is not mentioned anywhere or did I jsut not find it? I was wodnering all the time, how ispconfig knows I employed the chroot how-to
Oh, I just foudn out my ssh users were no longer chrooted :-( it seems one of the apt-get dist-upgrades broke the jail :-( I guess it was an update of sshd? Meaning after any sshd upgrade I have to redo the chroot howto? How can I block the sshd from being upgraded? anything else one needs to take care of?
openssh package You have to compile your version of openssh by yourself, see: http://chrootssh.sourceforge.net and, yes, look again at the tutorial - there is a hint preventing ssh from being updated: but I guess, after a dist-upgrade the old "holds" get lost. You can test your holded ssh package at any time by: Maybe it's a good idea to put generally some system testing in your crontab and getting notified in case your chroot or even other sensible system points got broken. Crontab entries survive dist-upgrades. But probably a much easier way to maintain things is to give your semi trusted users a special bash link that is restricted by apparmor.
thx, I must have overlooked the section where we were advised how to put openssh-server on hold. If you have further links, to read more about apparmor, feel free to psot here or PM me
AppArmor Nice Intro: Crispin Cowan (the AppArmor project lead) gave an interesting talk at FOSDEM 2006 via http://ftp.heanet.ie/mirrors/fosdem-video/2006/FOSDEM2006-apparmor.avi (271 MB) Other stuff easy to find by SE's. Warning! The coop with ISPConfig has to be carfully observed. Tim was warning about using AppArmor all the time. After installation at least bring really all confined services in complained mode (logging only) and please don't play around in production environments. So I can't tell you more, it's still on my TODO list to get this working and diving deeper into using AppArmor together with ISPConfig. I guess, it is one of the most promising ways to really solve all the annoying security problems around mod_python, mod_ruby and, as I hope, PHP without SAFE MODE and without "disable functions".
anyone noticed that after upgrading from debian 4.0 to 5.0 there are some problems with this solution: http://www.howtoforge.com/chrooted_ssh_howto_debian and as I retried it, the link to the patched openssh serevr are broken. is tehre a newer version of this guide available somewhere?
The latest OpenSSH versions (since 4.8: http://openssh.org/txt/release-4.8 ) support chrooted SSH out of the box, so there's no need for a patch anymore.
THX great news. but how do I get rid of the old stuff done during that how to? or is it enought if I just allow that package to be updated again by the system?
I think I'd install the OpenSSH package from Lenny (version 5.1 or something like that) and then play around with the ChrootDirectory directive a bit. Not sure if anything needs to be undone.