Jailing SSH users using debootstrap
From time to time, I need to provide access to my local Linux servers to certain users to share data. Although these users are trustworthy enough to access my local server and the access is temporary, I prefer to isolate them.
This isolation was traditionally achieved using chroot, but chroot has several drawbacks:
- You need to manually copy all the software and dependencies into the chroot environment.
- Keeping them updated to avoid security issues requires additional effort.
Twenty years ago, in one of my customers we were running a chrooted Postfix installation managing more than 100.000 users on Red Hat Enterprise Linux 5.x. At the same time, we also had chrooted Bind and NTP services running on Debian.
One day, after upgrading the RHEL 5.x server where Postfix was running, we noticed that Postfix had stopped sending emails, and its queue was growing rapidly. After some investigation, we realized that while we had upgraded the RHEL 5.x server, we had forgotten to update the chroot environment. This version mismatch caused Postfix to stop functioning.
However, we never experienced that problem with the Debian chroots.. This is because Debian includes an incredible tool called debootstrap. This tool allow you to deploy a Debian system into a directory. This tool allows us to deploy a Debian system into a directory, enabling us to chroot into it and manage the entire environment using the package manager (aptitude, apt, dpkg, or dselect).
If you're wondering whether this type of deployment might be heavy on disk space, I will tell you that my OpenSSH environment is only 394 Megabytes.
Currently, my server hosts two SSH services:
- A full-time SSH server which is the one I use.
- A secondary SSH server which I start only when I need to provide temporary access to someone. This secondary server runs in a chroot environment created using debootstrap.
Installing the software
My server is running Debian Testing (bookworm / 12.8 ). We need to install the following:
root@lezo:~# apt install debootstrap schroot --yes
Configuring the chroot environment
We will use schroot to manage the chroot environment. The first step is to create a profile for the chroot environment:
root@lezo:~# mkdir /etc/schroot/sshusers
root@lezo:~# chmod 0755 /schroot/sshusers
Now, we will create these files with perms 0644:
root@lezo:~# cat /etc/schroot/sshusers/copyfiles
# Files to copy into the chroot from the host system.
#
# <source-and-destination>[ <destination>]
/etc/resolv.conf
/etc/motd
root@lezo:~# cat /etc/schroot/sshusers/fstab
# fstab: static file system information for chroots.
# Note that the mount point will be prefixed by the chroot path
# (CHROOT_PATH)
#
# <file system> <mount point> <type> <options> <dump> <pass>
/proc /proc none rw,bind 0 0
/sys /sys none rw,bind 0 0
/dev/pts /dev/pts none rw,bind 0 0
root@lezo:~# cat /etc/schroot/sshusers/nssdatabases
# System databases to copy into the chroot from the host system.
#
# <database name>
services
protocols
networks
root@lezo:~#
These files will be used to configure the chroot environment by copying host databases, files, and creating the necessary mount points. Since we do not want to expose sensitive information from the host system to the chroot environment, we will not use the passwd and shadow hosts databases within the chroot.
Keep in mind that I will maintain two distinct and isolated SSH environments.
Now we will define our chroot environment:
root@lezo:~# cat /etc/schroot/schroot.conf
# schroot chroot definitions.
# See schroot.conf(5) for complete documentation of the file format.
#
# Please take note that you should not add untrusted users to
# root-groups, because they will essentially have full root access
# to your system. They will only have root access inside the chroot,
# but that's enough to cause malicious damage.
#
# The following lines are examples only. Uncomment and alter them to
# customise schroot for your needs, or create a new entry from scratch.
#
#
[openssh]
description=Chroot for ssh untrusted users
aliases=users
type=directory
directory=/opt/chroot-users
root-groups=root
profile=sshusers
personality=linux
preserve-environment=true
root@lezo:~#
Creating the chroot environment using debootstrap
The first step is to create the directory where the chroot environment will be deployed. The directory path will be /etc/schroot/schroot.conf:
root@lezo:~# mkdir /opt/chroot-users
And now we will deploy a Debian system on that directory using debootstrap:
root@lezo:~# debootstrap stable /opt/chroot-users http://deb.debian.org/debian/
This will take a while.
You can see that we are deploying a Debian stable (12.8) inside the chroot, while the host is running the testing version. We can deploy any Debian version using debootstrap regardless of the version running on the host.
Once the deployment has finished we are ready to start working with the chroot.
Working with the chroot environment
To work with the chroot environment we only need to do:
root@lezo:~# schroot -c users
(openssh)root@lezo:~#
And now we can upgrade packages, install/remove packages as needed.
Now, we need to install the openssh server:
(openssh)root@lezo:~# apt install openssh-server openssh-sftp-server --yes
We can install aditional software if needed, but as this environment is only intended for occasional data sharing, no further software will be installed.
After installing the software, you must harden the SSH configuration and configure additional security measures according to your paranoia mental state :-P.
Don’t forget to configure different ports for the SSH services, as you will have two separate SSH services running.
Creating users in the chroot environment
The users will be created as usual, but they must be created from the chroot environment itself:
(openssh)root@lezo:~# useradd -- -md /home/guest -u guest -s /bin/bash guest
Starting the chrooted SSH service
To start the SSH service:
root@lezo:~# schroot -c users
(openssh)root@lezo:~# /etc/init.d/ssh start
Starting OpenBSD Secure Shell server: sshd.
(openssh)root@lezo:~#
And now, your chroot users are allowed to access the system, but they will be jailed:
jadebustos@archimedes:~$ ssh -p 4321 guest@192.168.1.150
Last login: Tue Dec 24 11:44:48 2024 from 192.168.1.138
(openssh)guest@lezo:~$


Comments
Post a Comment