Our solution is to create a main user account for each customer, such as flowershop
. Each customer can create an arbitrary number of side accounts with their own passwords, such as flowershop_developer
, flowershop_tester
, flowershop_dba
, etc. This allows them to hand out accounts without sharing their main account password, which is better for a whole bunch of reasons (for example, if they need to remove their DBA's account, they can easily do that without changing their own passwords).
Each one of these accounts is in the flowershop
group, with a home folder of /home/flowershop/
. SSH uses this as the chroot directory (/home/%u
, as shown in the configuration in the question).
We then use ACLs to enable every user in group flowershop
to modify all files. When a new customer account is created, we set the ACLs as follows:
setfacl -Rm \
d:group:admin:rwx,d:user:www-data:r-x,d:user:$USERNAME:rwx,d:group:$USERNAME:rwx,\
group:admin:rwx, user:www-data:r-x, user:$USERNAME:rwx, group:$USERNAME:rwx \
/home/$USERNAME/
This does the following:
- Gives group
admin
(for us, the hosting providers) rwx
- Gives user
www-data
(Apache) r-x
to the files*
- Gives user
$USERNAME
rwx
to the files
- Gives group
$USERNAME
rwx
to the files
This setup appears to be working well for us, but we are open to any suggestions for doing it better.
* we use suexec for CGI/PHP running as the customer account
Best Answer
If you don't want to hack the openssh code you have to use the external sftp server. If you do it is a simple matter of putting a wrapper around it. For example: in
sshd_config
In
/usr/local/bin/sftp-server
:It might be possible to put a wrapper around
sshd
and launch the wrapper frominetd
but launchingsshd
frominted
is discouraged because it is to slow to start up.