Chroot SSH + ISPConfig

[falko]

Originally Posted by jonwatson

but can the site that the new users belong to exist before turning it on?

Yes, that's no problem.

[jonwatson]

Ok..so

I guess no one knows how to fix this? I have the same problem on all three of my ISPConfig installs. Two Ubuntu 6.06 and one Debian 3.1.

[jonwatson]

Originally Posted by jonwatson

Ok..so

I guess no one knows how to fix this? I have the same problem on all three of my ISPConfig installs. Two Ubuntu 6.06 and one Debian 3.1.

OK, totally frustrated now. I'm not sure why I can't get any help on this issue, but it's been what...two weeks messing with this?

I hate to do this but I'm going to have to leave ISPConfig over this. I simply cannot run a hosting site that allows users to stomp all over each other's home directories. I'm really against leaving ISPConfig because I'm a huge open source supporter and I'm going to have to go with a proprietary system for this, but I see no option. Not being able to chroot SSH users is a fatal flaw.

Does anyone have ANY last things I can try before I start rebuilding my server? Anything at all...?????

[till]

Chrooting SSH users is really easy, I dont know why it works not for you on your system. The only thin you have to do is to compile a SSH daoemon with chroot SSH support and then enable chrooting in ISPConfig. I've done this on many servers and it always worked prefectly for me.

[jonwatson]

Originally Posted by till

Chrooting SSH users is really easy, I dont know why it works not for you on your system. The only thin you have to do is to compile a SSH daoemon with chroot SSH support and then enable chrooting in ISPConfig. I've done this on many servers and it always worked prefectly for me.

I agree that I seem to be having more problems than some, but I now have three ISPConfig boxes which exhibit the same symptoms. CHROOTing doesn't work on any of them.

I followed Falko's tutorial (was it Falkos?) on installing the CHROOT environment in Debian. There were no obvious errors during the install and it seemed to go as planned.

I then enabled the chroot setting in the /home/admispconfig/ispconfig/lib/ispconfig.inc.php file by setting it to 1.

When I create new users, their passwd entry looks like this:

username:x:10009:10004:Working User:/var/www/web4/user/username/./:/bin/bash

(I've munged the username) but the '.' part is there which seems to be correct.

The CHROOT scripts seem to be copied over correctly as I see etc, bin, lib directories in the site's home directory.

Yes, whenever a user attempts to log in, they are punted with the error that /bin/bash cannot be found.

The bin directory in the site's home dir contains:

drwxr-xr-x   2 root             root    4096 Mar 24 11:01 .
drwxr-xr-x  12 munged.com web11   4096 Mar 25 11:41 ..
-rwxr-xr-x   1 root             root  625228 Mar 25 11:35 bash
-rwxr-xr-x   1 root             root   75948 Mar 25 11:35 ls
-rwxr-xr-x   1 root             root   20888 Mar 25 11:35 mkdir
-rwxr-xr-x   1 root             root   55340 Mar 25 11:36 mv
-rwsr-xr-x   1 root             root   30764 Mar 25 11:36 ping
-rwxr-xr-x   1 root             root   13848 Mar 25 11:36 pwd
-rwxr-xr-x   1 root             root   30712 Mar 25 11:36 rm
-rwxr-xr-x   1 root             root  163852 Mar 25 11:36 tar

So...I'm lost. Everything seems to be set up OK - but user's can't log in.

That's what I need help troubleshooting. There must be some reason why user accounts can't find /bin/bash once chrooted.

I am *extremely* motivated to fix this as I really can't fathom how I'm going to move my entire infrastructure off of ISPConfig.

[till]

Are you really sure that you run the SSHD that you compiled with chroot support and not accidently your old sshd?

Please post the output of:

locate sshd

(you must have the locate tool installed for this and maybe its a good idea to run the "updatedb" command before you execute the locate command.)

[jonwatson]

Originally Posted by till

Are you really sure that you run the SSHD that you compiled with chroot support and not accidently your old sshd?

Please post the output of:

locate sshd

(you must have the locate tool installed for this and maybe its a good idea to run the "updatedb" command before you execute the locate command.)

I never thought of that. I assumed the new installation of the patched SSH would overwrite the old one.

I don't see more than one, though....do you?

rex:/# locate sshd
/etc/logwatch/conf/services/sshd.conf
/etc/logwatch/conf/services/sshd2.conf
/etc/ssh/sshd_config
/usr/local/share/man/man5/sshd_config.5
/usr/local/share/man/man8/sshd.8
/usr/sbin/sshd
/usr/share/logwatch/scripts/services/sshd
/usr/share/logwatch/scripts/services/sshd2
/usr/share/man/man5/sshd_config.5.gz
/usr/share/man/man8/sshd.8.gz
/usr/share/vim/vim63/syntax/sshdconfig.vim
/var/run/sshd
/var/run/sshd.pid

[jonwatson]

Got it!

The file ld-linux.so.2 isn't being copied into the chrooted lib/ when new users are created. Without it, bash fails.

I'll investigate why this is and try to fix it. I assume I can add it to the create_chroot_env.sh script...

Edit:

There are actually two libraries that bash requires which are not copied over for some reason. They ARE listed in ldd so I don't know why they don't copy.

As a temporary kludgy hack, I have added the following two lines to /root/ispconfig/scripts/shell/create_chroot_env.sh

cp /lib/ld-linux.so.2 ./lib/ 
cp lib/tls/libdl.so.2 ./lib/tls/