So, I wouldn’t normally recommend this to customers. However, there are secure ways to add SFTP access, without the SFTP subsystem having to be modified. It’s also possible to achieve similar setup in a location like /home/john/public_html.
Let’s assume that public_html and everything underneath it is chowned john:john. So john:john has all the access, and apache2 runs with it’s own gid;uid. This was a pretty strange setup, and you don’t see it every day. But actually, it allowed me to solve another problem that I’ve been seeing/seeing customers have for a long time. That problem is the problem of effectively and easily managing permissions. Once I figured this out it was a serious ‘aha!’ moment!. Here’s why.
Inside the /etc/group, we find the customers developer has done something tragic:
[[email protected] public_html]# cat /etc/group | grep apache
But fine.. we’ll run with it.
We can see all the files inside their /home/john/public_html , the sight is not good
]# ls -al
drwxrwxr-x 27 john john 4096 Dec 20 15:56 .
drwxr-xr-x 12 john john 4096 Dec 15 11:08 ..
drwxrwxr-x 10 john john 4096 Dec 16 09:56 administrator
drwxrwxr-x 2 john john 4096 Dec 14 11:18 bin
drwxrwxr-x 4 john john 4096 Nov 2 15:05 build
-rw-rw-r-- 1 john john 714 Nov 2 15:05 build.xml
drwxrwxr-x 3 john john 4096 Nov 2 15:05 c
drwxrwxr-x 3 john john 45056 Dec 20 13:09 cache
drwxrwxr-x 2 john john 4096 Dec 14 11:18 cli
drwxrwxr-x 32 john john 4096 Dec 14 11:18 components
-rw-rw-r-- 1 john john 1863 Nov 2 15:05 configuration-live.php
-rw-r--r-- 1 john john 3173 Dec 15 11:08 configuration.php
drwxrwxr-x 3 john john 4096 Nov 2 15:05 docs
drwxrwxr-x 8 john john 4096 Dec 16 17:17 .git
-rw-rw-r-- 1 john john 1734 Dec 14 11:21 .gitignore
It gets worse..
# cat /etc/passwd | grep john
Now, adding an sftp user into this, might look like a nightmare, but actually with some retrospective thought it was really easy.
Solving this mess:
yum install scponly
Create new ‘SFTP’ user:
Create a password for user scponlyuser
Solution to john:john permissions
[[email protected] public_html]# cat /etc/group | grep john
We simply make scponlyuser part of the john group by adding the second line there. That way, the scponlyuser will have read/write access to the same files as the shell user, without exposing any additional stuff.
This was a cool solution to fixing this customers insecure solution, that they wanted to keep it the way they had, and was also great way to add an sftp account without requiring root jail. Whether it’s better than the root jail, is really debatable, however scponly enforces that only this account can be used only for SCP, as well as achieving sftp user access, without a jail.
I was proud of this achievement.. goes to show Linux permissions are really more flexible than we can imagine. And, whether you really want to flex those permissions muscles though, should be of concern. I advised this customer to change this setup, remove the /bin/sh, among other things..
We finally test SFTP is working as expected with the new scponlyuser
sftp> rmdir test
sftp> get index.php
Fetching /home/john/public_html/index.php to index.php
/home/john/public_html/index.php 100% 1420 1.4KB/s 00:00
sftp> put index.php
Uploading index.php to /home/john/public_html/index.php
index.php 100% 1420 1.4KB/s 00:00
sftp> mkdir test
sftp> rmdir test
Just replace ‘scponly’ with whatever username your setting up. The only part that you need to keep the ‘scponly’ bit, is /usr/bin/scponly, this is the environment logging into. Apologies that scponly is so similar to scponlyuser ;-D
I was very pleased with this! Hope that you find this useful too!