Prevent ssh access view of other directories?

[PermaNoob]

Is there a way to prevent clients who login with ssh clients like winscp from seeing the contents of directories other than their own?

I know I have clients who wouldn't be too happy with other people knowing what's in their directories.

I've been testing out my new server with ISPconfig before I move any clients over, and this could be a problem.

[till]

You must use chrooted SSH:

http://www.howtoforge.com/forums/showthread.php?t=8677

or search the forums for:

chroot ssh

[PermaNoob]

If I do this, is it going to screw up my ISPconfig installation? :

1 Install The Newest Zlib Version
Because there was a security hole in zlib-1.2.2 about which the chrooted SSH will complain when we try to compile it, we install the newest zlib version right now:

cd /tmp
wget http://www.zlib.net/zlib-1.2.3.tar.gz
tar xvfz zlib-1.2.3.tar.gz
cd zlib-1.2.3
make clean
./configure -s
make
make install


2 Install The Chrooted SSH

This is quite easy. We download the patched OpenSSH sources, and we configure them with /usr as directory for the SSH executable files, with /etc/ssh as directory where the chrooted SSH will look for configuration files, and we also allow PAM authentication:

cd /tmp
apt-get install libpam0g-dev openssl libcrypto++-dev libssl0.9.7 libssl-dev ssh
wget http://chrootssh.sourceforge.net/dow...-chroot.tar.gz
tar xvfz openssh-4.2p1-chroot.tar.gz
cd openssh-4.2p1-chroot
./configure --exec-prefix=/usr --sysconfdir=/etc/ssh --with-pam
make
make install

[martinfst]

It won't screw you ISPConfig environment, but notice, you will have the same restrictions. So after chrooting ssh, you yourself are also bound by the limitations of a chroot-ed environment. Which means, if you ever need to look at e.g. a logfile you have to go over to the console. That's fine if you're close to your server, but my servers are located in different external datacenters, not all of them close to where I live.

[PermaNoob]

Martin, that's no problem if I use putty to ssh in as root, is it?

[edge]

Originally Posted by PermaNoob

Martin, that's no problem if I use putty to ssh in as root, is it?

as root you can access everything okay!

[martinfst]

Yes, but I've disabled direct root login in my ssh server. That way, 'they' have to crack at least two passwords. So that wouldn't work for me, I think.

I've never set this up. To test it (if your not close to the console) I'd do:

1. login to at least two or three ssh sessions
2. change everything to chroot ssh
3. Restart ssh deamon on your server. Existing sessions are not affected
4. login with yet another session
5. test if you can do: su -
6. verify if you have access to the absolute root directory of your server
7. if not, immediately disable chrooted ssh, try to find the answer why it didn't work, fix it, and repeat the sequence above.

Even better is to test this on a spare local machine....

[edge]

Yes, but I've disabled direct root login in my ssh server. That way, 'they' have to crack at least two passwords. So that wouldn't work for me, I think.

Login as normal users, and than use the command su (super user) and enter the root password.

After this you are loged in as root.

[jnsc]

Just to correct a common error: su does not mean super user but substitute user

[martinfst]

Originally Posted by jnsc

Just to correct a common error: su does not mean super user but substitute user

100% correct. It will give you super user rights is used without a user argument.
That's why I use

su -

, which is as close as you can get on my systems as root (besides connecting a screen and keyboard on the console ports). Try

id

It will show you are root.
Nah, I even don't use that (su -) anymore. I've modified my /etc/sudoers file to be able to do what needs to be done, without ever having the need to directly logon as root.

Errrrrm, maybe we should keep an eye on the original question about chroot-ing ssh and the implications that may have on accessing a system. My apologies for the more-or-less off-topic drifting of this thread. I'm afraid I've been responsible for that.