There are different ways to lock a user into his home directory. A very special case is to grant sftp-only access, which does not require a full chroot jail to be set up. The sftp subsystem built into openssh allows a simple setup of a user locked into his home directory.
Configure OpenSSH
There are two ways to configure OpenSSH. Individual users can be configured in openssh or (my preferred solution) a group can be created and configured in OpenSSH. This group can then be assigned to the users who should be restricted to sftp only. Edit the /etc/ssh/sshd_config file and include the following section at the end of the file.
Match Group sftponly
ChrootDirectory %h
ForceCommand internal-sftp
The above configuration section (the “Match” block) must be the last configuration item in the config file. Any configuration following a Match block overrides the general settings when the Match conditions are met. In the above example, the two configuration items are only used when the user is part of the “sftponly” user group. The “ChrootDirectory” locks the user into the directory specified as argument. The “%h” represents the user’s home directory, allowing the match pattern to lock each user into his own home directory. The “ForceCommand” ensures that the user cannot trigger any other command, but only enter the “internal-sftp” subsystem.
It is also necessary to configure the sftp subsystem to use “internal-sftp”. Also in the /etc/ssh/sshd_config ensure the following configuration is set. Otherwise the external sftp-server will be used, which can not be found inside the chroot jail of the user.
Subsystem sftp internal-sftp
The configured group needs to exist on the system to assign it to the sftp users. The following command will create this group.
$ groupadd sftponly
Finally the ssh daemon needs to be restarted to load the new configuration.
$ systemctl restart sshd
Further restricting the account
To ensure the sftp only user is only allowed to use sftp, additional restrictions can be added to the match block.
Match Group sftponly
ChrootDirectory /home/%u
ForceCommand internal-sftp
AllowTcpForwarding no
PasswordAuthentication no
X11Forwarding no
Some of the most common restrictions are shown in the example above.
AllowTcpForwarding – Deny TCP forwarding which can be used to forward certain ports
PasswordAuthentication – Disable password authentication. The user can only authenticate with any remaining methods, like ssh-keys.
X11Forwarding – Deny X11 forwarding to protect any X11 interaction to the server.
Choose the settings for further restriction of the account based on your needs. In some cases, disabling Password authentication might be required to be disabled.
Preparing the Account
A new sftp only account can now be created and prepared. As described above, the user needs to be assigned to the group used in the Match block.
$ useradd -G sftponly -s /sbin/nologin user1
The “-G” option adds “sftponly” as a supplementary group to the user “user1”. With the “-s” option, the user gets “/sbin/nologin” as shell which denies interactive shell access for the user. This command will automatically (if not instructed otherwise with additional arguments) create a home directory for the user. The permissions of the home directory need to be modified for the chroot jail to work.
$ chown root /home/user1
The user “root” needs to be set as the owner of the home directory. The group should remain the primary group of the user as the user needs to access the directory. The permission set with the following command should ensure the user “user1” can access the home directory.
$ chmod g+rx /home/user1
Do not set the group’s write permission as it will be checked by ssh during login. The ssh daemon will refuse login attempts with the following error if the write permission is granted.
Authentication refused: bad ownership or modes for directory /home/user1
The permission can either be granted by just adding the read and execute permission to the group as shown in the above command or numerically as “0750” setting implicit permission for user, group and other.
Limitations of this setup
This specific setup has one drawback caused by the fact that the user’s home directory owner is root. The user itself has no write permission to his home directory. So the user can not create new directories or files directly directly in the home directory. Above, the owner of the home directory was set to root to allow the chroot jail to work. That change prevents the user from writing directly into the home directory. Granting the user’s group write permission to the home directory will not be possible.
To allow the user to upload content via sftp, a subdirectory should be created for this purpose. The created directory’s owner will be the user, allowing him to manage files and directories within the subdirectory freely.
$ mkdir /home/user1/data $ chown user1:user1 /home/user1/data
The above example creates a directory called “data” in the user’s home directory and changes the owner of it to the user. Now the user can manage data inside this directory. In some web-hosting scenarios the directory is named “public_html”. This allows the user to upload web-content while still being locked into his home directory.
Authorized keys
To be able to configure an authorized key for the user, the “.ssh” directory must be created and changed to the correct owner and permission.
$ mkdir /home/user1/.ssh $ chown user1:user1 /home/user1/.ssh $ chmod 0700 /home/user1/.ssh
With the .ssh directory prepared and owned by the user, the user can upload his key already by himself as needed. For more details about adding a key, see SSH passwordless login with SSH-key.
Test the configuration
To test the configuration, connect with the sftp command line client as shown below.
$ sftp user1@sftp.example.com
Depending on the configuration, you will either see the prompt “sftp>” or, if no ssh-key was yet added, you will be prompted for the password of the user.
Verify that the user is locked inside the home directory by checking the current working directory (command: “pwd”) and the directory content (command: “ls”). The users home directory should be represented by “/” indicating the root directory in which the user is locked in.
Should there be any issues with the connection or the acceptance of the ssh-key, the sftp client allows to pass ssh options using the “-o” option.
$ sftp -o LogLevel=DEBUG1 user1@sftp.example.com
The above example will try to connect to the server with the ssh log level set to debug. This will provide more details about problems from the client’s perspective.
On the server the log files will provide information about what went wrong. On RedHat based distributions, the related log is “/var/log/secure”. Even the ssh daemon on the server supports the “LogLevel” setting in the /etc/ssh/sshd_config file.
Read more of my posts on my blog at https://blog.tinned-software.net/.
