Chrooting is always a great option when you want to roll out a service that will be accessed by a lot of users, even more so if it’s on the internet. On OpenSSH’s sftp server, chrooting is a couple of lines of setup away. You can add ACL on top of that to get more granular and complex access rules
First, the folders or directories. All directories that will be chrooted must belong to root. This is why most of the time, we need to create new directory structure for the chrooted accounts. For the purpose of this post, I’ll be making these:
surfer@sclaw:~$ sudo mkdir /files surfer@claw:~$ sudo mkdir /files/surveyor surfer@sclaw:~$ sudo mkdir /files/surveyor/user01 surfer@claw:~$ sudo mkdir /files/surveyor/user01/incoming surfer@claw:~$ sudo mkdir /files/surveyor/user02 surfer@claw:~$ sudo mkdir /files/surveyor/user02/incoming
And assign them to root
surfer@claw:~$ sudo chown -R root.root /files/
Next, the users. It is important that we make sure that the sftp users can only access the server via sftp, and they should have no access to any kind of shell:
surfer@claw:~$ sudo useradd -d /files/surveyor/user01 -s /sbin/nologin user01 surfer@claw:~$ sudo useradd -d /files/surveyor/user01 -s /sbin/nologin user02 surfer@claw:~$ sudo useradd -d /files/surveyor/ -s /sbin/nologin traffic01 surfer@claw:~$ sudo useradd -d /files/surveyor/ -s /sbin/nologin traffic02 surfer@claw:~$ sudo groupadd surveyor surfer@claw:~$ sudo groupadd traffic surfer@claw:~$ sudo gpasswd -a user01 surveyor surfer@claw:~$ sudo gpasswd -a user01 surveyor surfer@claw:~$ sudo gpasswd -a traffic01 traffic surfer@claw:~$ sudo gpasswd -a traffic02 traffic surfer@claw:~$ sudo chown -R user01.user01 /files/surveyor/user01/incoming surfer@claw:~$ sudo chmod -R 700 /files/surveyor/user01/incoming surfer@claw:~$ sudo chown -R user02.user02 /files/surveyor/user02/incoming surfer@claw:~$ sudo chmod -R 700 /files/surveyor/user01/incoming
Notice that user traffic01 and traffic02 have different kind of home directory setup and belong to a different compared the first two users. That is because I have a slightly different plan for these guys. The user traffic01 and traffic02 are to be able to access all data inside user01 and user02’s incoming folder respectively.
Aside from that, all three directed to /sbin/nologin for shell access. I also assign ownership of “incoming” folder to their corresponding accounts
On to the sftp server. Here are a couple of lines that you can put on /etc/ssh/sshd_config:
Match Group surveyor ChrootDirectory %h ForceCommand internal-sftp Match Group traffic ChrootDirectory /files/surveyor ForceCommand internal-sftp
The first group of lines establishes that all users that belong to the group surveyor are chrooted to each of their home directory. The second group of lines confines any members of the group traffic to directory /files/surveyor, in this case “traffic01” and “traffic02”. Restart the ssh server for the changes to take effect.
Logging in to a shell with these accounts should give you this
surfer@talon:~$ ssh email@example.com firstname.lastname@example.org's password: This service allows sftp connections only. Connection to claw.cloudapp.net closed. surfer@talon:~$
if you log in as user01 or user02 using sftp client
Connected to claw.cloudapp.net. sftp> ls incoming sftp> pwd Remote working directory: / sftp> cd / sftp> ls incoming sftp> cd .. sftp> ls incoming sftp> put exam.txt Uploading exam.txt to /exam.txt remote open("/exam.txt"): Permission denied sftp> cd incoming sftp> put exam.txt Uploading exam.txt to /incoming/exam.txt exam.txt 100% 70 0.1KB/s 00:00 sftp>
As you can see, user01 can’t get out of his home directory, and can’t write on his home directory since it belong to the root account. It can, however write on the “incoming” directory. As for user traffic01 and traffic02:
surfer@M5-F-x-II:~$ sftp email@example.com firstname.lastname@example.org's password: Connected to claw.cloudapp.net. sftp> ls user01 user02 sftp> cd user01 sftp> ls incoming sftp> cd incoming sftp> ls remote readdir("/user01/incoming"): Permission denied sftp>
This is of course expected, since I did chmoded the directory only accessible by its’ owner. I do however, want to give write access to these folders to “traffic01”, which in turn, bring us to the second part of this post. Using ACL.
ACL provides the ability to modify the access mode beyond linux standard combination of owner, group, and other. On Ubuntu, you can get it by doing
surfer@claw:~$ sudo apt-get install acl
There are two important command that come with ACL. The first one is “setfacl”, used to set the access mode to files or folders. As an example, for the purpose of this tutorial, I will do
surfer@claw:~$ sudo setfacl -Rdm u:traffic01:r-x /files/surveyor/user01/incoming
This will give the user traffic01 read access to /files/surveyor/user01/incoming, on top of the chmod 700 established earlier. “R” is obviously for applying the change recursively to everything inside the folders, and “d” will set the access rule as default for everything else copied or created into that particular folder in the future, while “m” is for “modify, simply signifying that the action is modifying existing rules for that folder.
The second command is getfacl that you can use to retrieve active ACLs on a particular folder. For example:
surfer@claw:~/script$ sudo getfacl /files/surveyor/user01/incoming getfacl: Removing leading '/' from absolute path names # file: files/surveyor/user01/incoming # owner: user01 # group: user01 user::rwx group::--- mask::--- other::--- default:user::rwx default:user:traffic01:r-x default:group::--- default:mask::rwx default:other::---