Setting Up a Chrooted SFTP Directory

At some point you might find yourself in a situation where you need to grant sftp access to a user but it should be configured to prevent them from traversing the entire directory structure within the system. This is where the built-in chroot functionality within sshd comes in handy. It will enable you to restrict and isolate the user to a specific directory and easily prevent unauthorized access. In this example, we will cover the configuration steps for setting up access for one user named jsmith within the Accounting department.

1. Create the User

As the root user, create the account & password for jsmith. We will specify the home directory as /var/accounting. This will be the chrooted directory we are going to setup. The shell should be /bin/false to prevent any interactive shell logins.

# useradd jsmith -d /var/accounting -s /bin/false
# passwd jsmith

Note: Although the user will be forced into /var/accounting regardless of what you specify, not doing so would automatically create an unnecessary /home/jsmith directory that could cause issues in the future.

2. Set Up the Chrooted SFTP Directory

As root, create the chrooted directory. Root ownership and default 755 permissions should be automatic.

# mkdir /var/accounting

3. Update the SSHD Configuration

Backup your sshd_config file before starting to edit using vi,

# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bk
# vi /etc/ssh/sshd_config

First, search for the Subsystem sftp line,

Subsystem sftp /usr/lib/openssh/sftp-server

and modify it to look like this,

Subsystem sftp internal-sftp

This will ensure that the sftp subsystem is linked to the internal-sftp command, which is required for the chrooted setup.

Next, add the following options below the Subsystem that will correspond to the match on user jsmith,

Match User jsmith
    ChrootDirectory /var/accounting
    ForceCommand internal-sftp
    AllowTcpForwarding no
    PasswordAuthentication yes
    PermitTunnel no
    AllowAgentForwarding no
    X11Forwarding no

Note:

ChrootDirectory /var/accounting specifies the destination directory for the user

ForceCommand internal-sftp ensures only SFTP is allowed

AllowTcpForwarding no disables TCP forwarding

PasswordAuthentication yes allows password-based authentication

PermitTunnel no disables tunneling preventing the user from creating tunnels

AllowAgentForwarding no disables agent forwarding which restricts authentication forwarding

X11Forwarding no removes X11 forwarding preventing graphical interface forwarding

Although the last 3 options are not needed, including these will help to strengthen the isolation and security of the chrooted environment.

4. Restart SSH Service

After making changes and saving the sshd_config file, restart the sshd service,

# service sshd restart

5. Verify access

From a remote machine, sftp into the server as jsmith and verify the user is correctly restricted to /var/accounting,

# sftp jsmith@sftpserver
jsmith@sftpserver's password:
Connected to sftpserver.
sftp> cd /
sftp> pwd
Remote working directory: /
sftp> ls
sftp> quit

As you can see, from the user’s perspective, /var/accounting is their root and running ls shows no files within the directory.

Final Note

Within the /etc/ssh/sshd_config file, you could also use the Match Group directive instead of Match User if you were enabling access to multiple users with similar access. If you placed all the users within the sftp_users group, a Match Group block might look like this,

Match Group sftp_users
    ChrootDirectory /var/sftp_users
    ForceCommand internal-sftp
    AllowTcpForwarding no
    PasswordAuthentication yes
    PermitTunnel no
    AllowAgentForwarding no
    X11Forwarding no

The Match Group function does have the advantage of better user management and is easily scalable as compared to multiple Match User blocks. Regardless of which direction you go, make sure to verify the user is indeed chrooted and does not have access beyond what is required.