SSH jails
15 Replies
Chroot location: /home/user/
cp /bin/rm /home/user/bin/rm
And you'll have to copy libraries over as well, check with the command ldd /bin/rm which libraries are required and copy them over to the chrooted location.
@Nuvini:
It's the same as SFTP jails, but this time do assign a shell. You'll have to set up a filesystem in the chrooted environment though. so if you would need the command rm:
Chroot location: /home/user/
cp /bin/rm /home/user/bin/rm
And you'll have to copy libraries over as well, check with the command ldd /bin/rm which libraries are required and copy them over to the chrooted location.
Thanks. I wasn't able to make anything useful of the command though.
@Inquisitor Sasha:
Is /home/user the best place for the chroot location? Where would the SSH jailed users' home directories go? Also, does this end up creating a different PHP version for the jailed SSH users? I remember that was a problem at GoDaddy shared hosting; they used version 4.9.9 for SSH.
You would set up the chroot by copying stuff directly from the host, so the version of PHP being used is whichever version you copied. Keep in mind that whenever you update the host, you should also update the chroot.
Alternatively, instead of doing a direct copy, you could check if the base package manager (e.g. rpm, dpkg, etc.) supports specifying which directory to use as the system root – that would allow you to set up a chroot using packages direct from your distros packages, effectively allowing you to push the responsibility of system updates through the normal package manager (apt, yum, ect.) to your users. The two downsides here are: you may have to do some manual dependency resolution until you have it setup, and some users may have issues remembering to update.
I've never set up a ssh jail, so I don't know where best to put it.
Ideally, you should either copy individual files as Nuvini suggested, or use distro packages and specify a chroot as I suggested.
If you use Nuvini's suggestion, you'd need to set up the chroot to resemble the host directory structure. At a minimum, you need the following directories:
/bin
/dev
/etc
/home
/lib
/proc
/root
/sbin
/sys
/usr
/usr/bin
/usr/include
/usr/lib
/usr/sbin
/usr/share
/usr/share/man
/var
/var/cache
/var/lib
/var/local
/var/log
/var/run
You can see in detail what is supposed to be included in the Filesystem Hierarchy Standard
If there's a method that doesn't involve recreating the operating system in the chroot, that would be best since otherwise it would take up too much disk space.
If you have a spare Linode or two, that would save you some space on your main 'Node.
@Piki:
You could try softlinking everything on the host into the chroot. Personally I haven't tried this, and haven't seen any reports of others trying, so I don't know how that would work out.
If you have a spare Linode or two, that would save you some space on your main 'Node.
Eh? You mean hard linking surely? Soft links will not be followed out of the chroot.
Hard links will only work if all involved files are on the same filesystem.
@sednet:
@Piki:You could try softlinking everything on the host into the chroot. Personally I haven't tried this, and haven't seen any reports of others trying, so I don't know how that would work out.
If you have a spare Linode or two, that would save you some space on your main 'Node.
Eh? You mean hard linking surely? Soft links will not be followed out of the chroot.
I get annoyed when people tell me what I mean.
I did not know softlinks would not be followed outside a chroot, so I certainly did mean softlinks. Hence my note about not having tried it.
@Piki:
@sednet:
@Piki:You could try softlinking everything on the host into the chroot. Personally I haven't tried this, and haven't seen any reports of others trying, so I don't know how that would work out.
If you have a spare Linode or two, that would save you some space on your main 'Node.
Eh? You mean hard linking surely? Soft links will not be followed out of the chroot.
I get annoyed when people tell me what I mean.
I did not know softlinks would not be followed outside a chroot, so I certainly did mean softlinks. Hence my note about not having tried it.
Rightie-o. Symbolic links are just references to another file to lookup. They don't even need to reference a valid file.
The normal approach is to copy whatever is needed into the chroot without any links to outside that chroot. That way if it all gets trashed nothing outside the chroot will be damaged.
@Piki:
@sednet:
@Piki:You could try softlinking everything on the host into the chroot. Personally I haven't tried this, and haven't seen any reports of others trying, so I don't know how that would work out.
If you have a spare Linode or two, that would save you some space on your main 'Node.
Eh? You mean hard linking surely? Soft links will not be followed out of the chroot.
I get annoyed when people tell me what I mean.
I did not know softlinks would not be followed outside a chroot, so I certainly did mean softlinks. Hence my note about not having tried it.
The issue here is how much I will need to copy. I don't want to copy an entire operating system because of how much space that will use. I then need to know what to copy.
@Inquisitor Sasha:
The issue here is how much I will need to copy. I don't want to copy an entire operating system because of how much space that will use. I then need to know what to copy.
Start with the basic commands that all the chroots need: ls, cp, mv, rm, ssh/sshd, su (and maybe sudo). Then add in everything else that's absolutely needed. What that is needs to be decided by you, e.g. if each user needs a web server, you'd include PHP and whichever web server daemon you use.
After you copy over all the binaries, use ldd as Nuvini suggested to figure out which libraries you need. To figure out the libraries for ls, you'd see something similar to:
piki@linuxjutsu:~$ ldd /bin/ls
linux-vdso.so.1 => (0x00007fff6a7ff000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f02d7c2c000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f02d7a24000)
libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f02d781a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f02d7490000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f02d728c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f02d7e54000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f02d706f000)
libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007f02d6e6a000)
It may appear a bit cryptic, but if you ignore the numbers it's a lot easier to figure out.