I'm in the process of migrating an aging shared-hosting system to more modern technologies. Right now, plain old insecure FTP is the only way for customers to access their files.

I plan on replacing this with SFTP, but I need a way to create multiple SFTP users that correspond to one UNIX account. A customer has one account on the machine (e.g. customer) with a home directory like /home/customer/.

Our clients are used to being able to create an arbitrary number of FTP accounts for their domains (to give out to different people). We need the same capability with SFTP.

My first thought is to use SSH keys and just add each new "user" to authorized_keys, but this is confusing for our customers, many of whom are not technically-inclined and would prefer to stick with passwords.

SSH is not an issue, only SFTP is available. How can we create multiple SFTP accounts (customer, customer_developer1, customer_developer2, etc.) that all function as equivalents and don't interfere with file permissions (ideally, all files should retain customer as their owner)?

My initial thought was some kind of PAM module, but I don't have a clear idea of how to accomplish this within our constraints. We are open to using an alternative SSH daemon if OpenSSH isn't suitable for our situation; again, it needs to support only SFTP and not SSH.

Currently our SSH configuration has this appended to it in order to jail the users in their own directories:

# all customers have group 'customer'
Match group customer
    ChrootDirectory /home/%u    # jail in home directories
    AllowTcpForwarding no
    X11Forwarding no
    ForceCommand internal-sftp  # force SFTP
    PasswordAuthentication yes  # for non-customer accounts we use keys instead

Our servers are running Ubuntu 12.04 LTS.

3 Answers 3


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 \
  group:admin:rwx,  user:www-data:r-x,  user:$USERNAME:rwx,  group:$USERNAME:rwx \

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


Not sure how the above solution helps answer the Op's problem. If flowershop_developer logs in, he will be chroot to /home/%u i.e /home/flowershop_developer directory. And similarly for other users.

How can they see the content of /home/flowershop directory if they are jailed to their home directory?

Hopefully I'm not missing something so trivial. I have a working solution using the mount -o bind option which would allows me to mount /home/flowershop within /home/flowershop_developer but was hoping there is an easier and elegant solution.


I'm not sure what you mean by "equivalents". Should all accounts have their own home directory? In that case just create individual accounts with individual home directories. Or should all accounts share the same home directory? That's probably not too good an idea, but you can create all accounts with the same primary (or supplemental) group, and use ACLs to handle permissions.

  • Ideally we'd prefer not to use UNIX accounts and read the accounts from MySQL or something instead of from /etc/passwd. Similar to how some FTP servers allow you to create arbitrary accounts/passwords (not tied to the system accounts/passwords). Sep 5, 2012 at 20:07
  • With those FTP servers, the filesystem permissions usually grant full access to the FTP server service account, and the FTP server then handles permissions for each user. That is not how SSH (or SCP/SFTP) works. If you want to avoid /etc/passwd, you have to integrate another backend for system authentication. I've seen some HOWTOs about using LDAP for this, but haven't yet implemented it myself. I don't know if MySQL can be used in the same way. Sep 5, 2012 at 23:27
  • 2
    As far as I'm aware "that's not how SSH works" isn't entirely true. It's not how the OpenSSH daemon implements it, but I don't think there's anything inherent in the protocol that prohibits using non-system accounts, especially since all we need is SFTP. I could be wrong of course. Sep 6, 2012 at 0:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .