Prevent ssh access view of other directories?

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.

 

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/download/openssh-4.2p1-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

 

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.

 

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

 

as root you can access everything okay!

 

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....

 

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.

 

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

Code:

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

Code:

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.

 

This is where I got the su "super user" from: http://www.computerhope.com/unix/usu.htm
It was the 1st page I got back from google searching for "linux su", but "super user"
As you can see on that page it does not say "substitute user"

The 2nd page I got back from google was: http://linux.about.com/od/commands/l/blcmdl1_su.htm
It's saying "substitute user"

So are the 3rd and 4th and .....

So.. ""substitute user" it will be

substitute user, does sound better

 

As I sais it's a common error, so you will find plenty of site which says super user

Code:

man su

Man says substitute user, so the lesson of this story is :
man 1
google 0

 

Following this chroot installation:

http://www.howtoforge.com/chrooted_ssh_howto_debian_p2

I get as far as pasting this into putty

-----------------------

APPS="/bin/bash /bin/ls /bin/mkdir /bin/mv /bin/pwd /bin/rm /usr/bin/id /usr/bin/ssh /bin/ping /usr/bin/dircolors"for prog in $APPS; do cp $prog ./$prog # obtain a list of related libraries ldd $prog > /dev/null if [ "$?" = 0 ] ; then LIBS=`ldd $prog | awk '{ print $3 }'` for l in $LIBS; do mkdir -p ./`dirname $l` > /dev/null 2>&1 cp $l ./$l done fi done

----------------------

then I get:

---------------------
-bash: syntax error near unexpected token 'do'
--------------------

I'm not a programmer--what do I do now?

 

For some reason, your copy/paste action removes the returns. It's now one long line, and you need to have the returns.

Can you open a text editor in your putty session and copy paste the text in there? Save the file, and execute

Code:

# chmod 755 <new_file_name>
# ./<new_file_name>

It's a trick but might work.

 

I made the file with returns to look exactly like the script is displayed. Thought it was going to work, but I got

cp: cannot stat `(0xffffe000)': No such file or directory
cp: cannot stat `(0xffffe000)': No such file or directory
cp: cannot stat `(0xffffe000)': No such file or directory
cp: cannot stat `(0xffffe000)': No such file or directory
cp: cannot stat `(0xffffe000)': No such file or directory
cp: cannot stat `(0xffffe000)': No such file or directory
cp: cannot stat `(0xffffe000)': No such file or directory
cp: cannot stat `(0xffffe000)': No such file or directory
cp: cannot stat `(0xffffe000)': No such file or directory
cp: cannot stat `(0xffffe000)': No such file or directory

 

Is there any way out of this?

 

My first impression is that your filesystem is corrupt. Did you have a power failure, cycled power without a shutdown?

 

No, the only thing that happened was the first part of that program ran I guess until the misplaced breaks...I think this part ran:

APPS="/bin/bash /bin/ls /bin/mkdir /bin/mv /bin/pwd /bin/rm /usr/bin/id /usr/bin/ssh /bin/ping /usr/bin/dircolors"for prog in $APPS;

Would that screw something up?