With the release of OpenSSH 4.9p1, you no longer have to rely on third-party hacks or complicated chroot setups to confine users to their home directories or give them access to SFTP services.
edit /etc/ssh/sshd_config (/etc/sshd_config on some distributions)
and set the following options:
Subsystem sftp internal-sftp
Match Group sftp
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
Ensure the “Match” directive is at the end of the file. This tells OpenSSH that all users in the sftp group are to be chrooted to their home directory (which %h represents in the ChrootDirectory command
For any users that you wish to chroot, add them to the sftp group by using:
# usermod -G sftp joe
# usermod -s /bin/false joe
# chown root:root /home/joe
# chmod 0755 /home/joe
The usermod command above will add user joe to the sftp group and set their shell to /bin/false so they absolutely cannot ever get shell access. The chown and chmod commands will set the required permissions for the directory. With these permissions set, the user will be allowed to upload and download files, but cannot create directories or files in the root directory
Chrooting shell accounts is a little more complicated as it requires that certain device files and a shell be available in the user’s home directory. The following commands will set up a very basic chroot system on Mandriva Linux:
# mkdir /chroot
# cd /chroot
# mkdir {bin,dev,lib}
# cp -p /bin/bash bin/
# cp -p /lib/{ld-linux.so.2,libc.so.6,libdl.so.2,libtermcap.so.2} lib/
# mknod dev/null c 1 3
# mknod dev/zero c 1 5
# chmod 0666 dev/{null,zero}
# mkdir -p /chroot/home/joe
With the above, user joe can ssh in and will be restricted to the chroot. Unfortunately, this doesn’t do much, but it gives you an idea of how it can be set up. Depending on what you want to provide, you will need to install additional libraries and binaries.
Creating a chroot
Install the dchroot and debootstrap packages.
As an administrator (i.e. using sudo), create a new directory for the
chroot. In this procedure, the
directory /var/chroot
will be used. To
do this, type sudo mkdir /var/chroot
into a command line.
As an
administrator, open
/etc/schroot/schroot.conf
in a text
editor. Type cd /etc/schroot
, followed
by gksu gedit schroot.conf
. This will
allow you to edit the file.
Add the
following lines into schroot.conf
and
then save and close the file. Replace
your_username
with your username.
[lucid]
description=Ubuntu Lucid
location=/var/chroot
priority=3
users=your_username
groups=sbuild
root-groups=root
Open a terminal and type:
sudo debootstrap --variant=buildd --arch i386 lucid /var/chroot/ \
http://mirror.url.com/ubuntu/
This will create a basic
'installation' of Ubuntu 10.04 (Lucid
Lynx) in the chroot. It may take a
while for the packages to be
downloaded. Note: You can replace
lucid with the Ubuntu version of your
choice. Note: You must change the
above mirror.url.com
with the URL of a
valid archive mirror local to you. A
basic chroot should now have been
created. Type sudo chroot /var/chroot
to change to a root shell inside the
chroot.
Setting-up the chroot
There
are some basic steps you can take to
set-up the chroot, providing
facilities such as DNS resolution and
access to /proc
.
Note: Type these commands in a shell
which is outside the chroot.
Type the following to mount the /proc
filesystem in the chroot (required for
managing processes):
sudo mount -o bind /proc /var/chroot/proc
Type the
following to allow DNS resolution from
within the chroot (required for
Internet access):
sudo cp /etc/resolv.conf /var/chroot/etc/resolv.conf
Very few
packages are installed by default in a
chroot (even sudo isn't installed).
Use apt-get install package_name
to
install packages.
Best Answer
Each new user connecting spawns a new
sshd
session with a specific PID. You could usepstree
to print which commands are inherited from whichsshd
session, and then cross check this PID in/var/log/auth.log
.Example (anonymized): I logged in to a remote server with 3 simultaneous sessions, with the same remote user. I now want to find out from which IP the client came that ran the command
watch date
.pstree -p
shows that thewatch
command is inherited fromsshd
with PID 15243.grep
ing for this PID in/var/auth/auth.log
shows that it was IP 12.34.56.78 that started this session. Therefore this is also the user that startedwatch
.As for finding
history
for specifically this user, it cannot be done from what I can see when all remote users are using the same local SSH user. Also, it can easily be spoofed/inactivated/etc., so it's not really reliable. If it is saved to the history file, then you could just look for thecp
command and look backwards in the file, but if it is not there, then there is not much to do.