Re: [suse-security] SSH and CHROOT alternatives...
Hi, I never did what you mean but here is what I have in mind. The problem with chroot with ssh (if it really can be run this way), seems to be that the users could not access /bin /usr/bin,etc so they can not even list files using ls. Of course you can copy this directories to the chrooted directory. To access the home you could use a workaround mounting the homes with nfs and using iptables to allow only localhost to use nfs at all. I think the easiest way is to get another machine just for ssh, and mount the home using nfs as soon as user logs in. You can also replace nfs for another network file system like samba. You can also forget about chroot and treat with the filesystem permission, puttin 700 mode on the directories you dont want users to access. Eg. you can let users access /usr, but not /var. In this case care must be taken on directories like /etc. Hope it helps Regards Jonathan
Howdoo all,
I've been looking at trying to secure SSH sessions so that specified users can only browse their home diretories.
I've found a couple of bodges that can be made to do the trick, but none of them seem particulalry ideal.
Has anyone got any suggestions on how I could secure SSH in this fashion, whether using CHROOT or something else entirely I don't mind.
Cheers.
----~~~~==oOo==~~~~---- Duncan Carter ----~~~~==oOo==~~~~----
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
On Thu, 22 May 2003 jonathanneto@indg.com.br wrote:
To access the home you could use a workaround mounting the homes with nfs and using iptables to allow only localhost to use nfs at all.
Instead of "loopback-nfs" there is now the better way of bind-mounts since kernel 2.4. mount --bind /home /chroot/home This comes handy for anonymous-ftp-chroot's too: mount --bind /bigspacewithfiles1 /usr/local/ftp/pub/1 mount --bind /bigspacewithfiles2 /usr/local/ftp/pub/2 c'ya sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/)
On Thu, May 22, 2003 at 06:46:26PM +0200, Sven Koch wrote: : On Thu, 22 May 2003 jonathanneto@indg.com.br wrote: : : > To access the home you could use a workaround : > mounting the homes with nfs and using iptables to allow only localhost to : > use nfs at all. Take a look at http://chrootssh.sourceforge.net. It's a lot easier than some of the other suggestions presented. --Jerry Open-Source software isn't a matter of life or death... ...It's much more important than that!
Hi, i guess there are 2 Ways to do the job: 1:] using Pub/Pirv. - Key Authenticating, with the chroot Command included in the public-Key of the user in known_hosts on the server. 2:] giving the user the chroot-command as default-Shell (witch might fail) For both: You need a {chroot}/dev/random in the chroot-jail (use mknod) and you need the commands the user should be able to use in {chroot}/bin (you might visit http://www.busybox.net/ ) For the /home/user use a _hardlink_ created by 1:] or 2:] this should work. (Did something similar 1 Year ago.) Greetings Dirk
-----Original Message----- From: jonathanneto@indg.com.br [mailto:jonathanneto@indg.com.br] Sent: Thursday, May 22, 2003 5:54 PM To: suse-security@suse.com Subject: Re: [suse-security] SSH and CHROOT alternatives...
Hi,
I never did what you mean but here is what I have in mind. The problem with chroot with ssh (if it really can be run this way), seems to be that the users could not access /bin /usr/bin,etc so they can not even list files using ls. Of course you can copy this directories to the chrooted directory. To access the home you could use a workaround mounting the homes with nfs and using iptables to allow only localhost to use nfs at all.
I think the easiest way is to get another machine just for ssh, and mount the home using nfs as soon as user logs in. You can also replace nfs for another network file system like samba.
You can also forget about chroot and treat with the filesystem permission, puttin 700 mode on the directories you dont want users to access. Eg. you can let users access /usr, but not /var. In this case care must be taken on directories like /etc.
Hope it helps
Regards Jonathan
Howdoo all,
I've been looking at trying to secure SSH sessions so that specified users can only browse their home diretories.
I've found a couple of bodges that can be made to do the trick, but none of them seem particulalry ideal.
Has anyone got any suggestions on how I could secure SSH in this fashion, whether using CHROOT or something else entirely I don't mind.
Cheers.
----~~~~==oOo==~~~~---- Duncan Carter ----~~~~==oOo==~~~~----
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
participants (4)
-
Dirk Schreiner -
Jerry A! -
jonathanneto＠indg.com.br -
Sven Koch