Configuring this properly required me to learn a few new things.

Where to store files

If you have files that should belong to a single user, place them in the user’s home folder.

/home/username/

If the files are shared across multiple users, place them in a folder under the service folder.

/srv/my-project/

This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed. Data that is only of interest to a specific user should go in that users’ home directory.

http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM

Depending on the purpose of the server, you need to decide if tasks are per-user or shared.

If you do decide to use the /srv/ folder, consider placing a symlink to the folder each user cares about inside the user’s home folder. This is simply to remind them that the data they care about is elsewhere.

As a Linux user, you probably know symlinks.

TARGET is something we want to reference, and name_of_link is where we want to put it (if you omit name_of_link, it gets placed in the current folder).

Generally speaking, this is the preferred way to link things on Linux.

Symlinks however do require that you have access to the file linked to. In other words, you have permission to manually go to the location of the file and use it. Later on when we start talking about jailing, this will be something we don’t have.

Hardlinks are created the exact same way as Symlinks, but without the -s.

Internally, a hardlink creates a brand new file that references the same data (inode) used by another file.

Using -i with ls shows the inode number. Every file has one. This is how you spot a hardlink. When 2 or more files share the same inode number, it’s not that one is a link to the other, they ARE the same file.

With that in mind, you can’t actually detect hardlinks like you can detect symlinks. When you delete a file on Linux, it doesn’t necessarily delete the file. Not until an inode runs out of references to to it is data deleted.

Important: Hardlinks can only be files. They can’t link folders. For what I’m doing here, I don’t need this feature, but I’ve included it for completeness.

To get the equivalent of a hardlink on a folder (i.e. access to the original isn’t required), you’ll need a binding mount.

This makes /else/where appear to contain everything /some/where did. Beware of recursion when mounting!

A mount can be made read-only like so:

The -o option is used to pass alternative options to mount. --bind is actually a shorthand for -o bind.

Reference: http://askubuntu.com/a/801191

Reference: http://unix.stackexchange.com/a/198591

Creating a jailed user

Before we make the jail, we need user(s) to put in the jail.

The disabled password is to disallow them from logging in via password authentication. Also for security’s sake, try to avoid making a jailed user a sudoer.

The above can be used to check the status of a user.

Display account status information. The status information consists of 7 fields. The first field is the user’s login name. The second field indicates if the user account has a locked password (L), has no password (NP), or has a usable password (P). The third field gives the date of the last password change. The next four fields are the minimum age, maximum age, warning period, and inactivity period for the password. These ages are expressed in days.

If we did things correctly, our user should have a locked password (L).

Reference: http://unix.stackexchange.com/a/184975

Setting up and generating RSA SSH keys for jailed users

On the client PC, you’ll need to generate a public+private key pair.

The default these days is RSA 2048. RSA 4096 is a bit safer, but it’s encryption so who knows for how long that will be the case. ECDSA (specifically ED25519) is on track to replace RSA, but the situation is a bit fishy right now (ECDSA has a potential hole, which ED works around, but it’s new’ish).

Then you’ll need to install the public key.

As root, you’d typically want to do this:

Then paste the contents of your id_rsa.pub file here.

Save the file, exit the user, and restart the SSH server.

You should now be able to connect to the server over ssh as the jailed user.

Addendum: There’s also a command ssh-copy-id that can be used to install the public key for you, but only if have password access.

Without access, this command is useless (included here just for reference).

Reference: http://askubuntu.com/a/46935

Setting up the Jail

Enabling the jail is actually really simple. The problem is the jail will have nothing in it.

Open up /etc/ssh/sshd_config

For simplicity, you should change the Subsystem line to the following:

Then at the end of the file you can add tiny bit of script to immediately lock the user in the jail.

Where username is the user’s name, and /home/username/my-prison is any folder you decide to make in to the root / folder. The folder should belong to the root user (even if it’s their home folder).

Save and restart the ssh server, and from now on, any time that user attempts to SSH in, they’ll get locked to that folder.

HOWEVER! The user lacking some basic tools. Most important: /bin/bash. Without /bin/bash, the connection will close immediately after logging in.

Now you need to build a filesystem.

Reference: https://www.linode.com/docs/tools-reference/tools/limiting-access-with-sftp-jails-on-debian-and-ubuntu

Reference: https://www.marcus-povey.co.uk/2015/04/09/cross-server-ssh-rsync-backups-done-more-securely/

Building the jailed users file system

You should do this as the root user.

NB: When I first started writing this note article, I expected I was going to use hardlinks to reference the currently installed version of all tools and libraries. While this does work, I realized there is an issue: dependency filenames. As long as dependencies don’t change filenames this is a non issue, but there is a change they may, as the OS updates. The chance of changes might be lower on an LTS version of Ubuntu, but I’m using a derived version of Ubuntu that regularly switches-out the Kernel. So instead, one should just cp the files, not hardlink them, and keep an ear out for known exploits of the tools you use.

Installing Bash (required to open an SSH connection and execute commands).

This will report to us what library dependencies bash needs to be run. The printout may look something like this.

What’s important is to pay attention to the lines with paths. All those /lib/‘s.

Using cp here makes this process far simpler. Many of these files are actually symlinks, so using a hardlink would create a dependency on yet another file.

That is everything needed to use Bash.

Installing rsync:

The process is fairly similar for other tools.

With the above 2 tools installed, you should be able to rsync to this machine… and that’s it. Other commands like ls or cp wont be available out-of-the-box, but an rsync-only user really shouldn’t need them anyway.