Goal: sftp/scp only access, without the need for linux users.

I want to provide 10 sftp/scp directories to 10 people. Let's call this "virtual account"

I don't want to create linux users for each of them.

I would like to create one linux user (backup_user). In his home-directory will be 10 directories. For each "virtual account" one directory.

Every virtual account must only see his own files, not the files from an other virtual account.

I would like to use the solution which is provided here: https://serverfault.com/a/88864/90324

In short there will be 10 lines in the authorized_keys file:


    "scp -v -r -d -t ~/CONTENT" ssh-rsa AAAAMYRSAKEY...

I could improve this by a python script and not use the hard coded "scp -v ...".

I would like to support scp and sftp.

Is there a way to chroot, to ensure each virtual account can't break out of his jail?

BTW: The idea with authorized_keys and "forced command" is just my current strategy. If there is a better way to each the overall goal, then please tell me :-)

We are running an OpenSSH server. I would like to stick to it, if possible.


We found a different solution: http. We developed a small and generic file http uploader: https://github.com/guettli/tbzuploader Feedback is welcome

  • 2
    Well, one simple thing comes to mind: use SSHd which doesn't use local users. Like wsftpd or maybe mina sshd
    – ptman
    Aug 31, 2017 at 18:38

4 Answers 4


This should be a comment, but its a bit long.

You've failed to adequately describe your objective. While I can make some inferences, extrapolating this to a proposal would be futile.

While there are tools available which allow you to create a server independent of the underlying users, these are cumbersome to setup and restricted in their ability to integrate with with other functions.

It would be much simpler to set up 10 users with keypair based logins and no shell access. But your only clearly stated constraint is that "don't want to create linux users for each of them" - but you provide no explanation of why. OTOH you state you want to use a method based on provisioning users in the OS.


I think that what you want (access without creating local user) is not possible with sshd.

Rather, you can use proftpd with virtual users (from, for example, a MySQL database) + the SFTP/SCP module.


What you want to do is more than a bit tricky. If you don't want to use a selfmade chroot-shoot-in-your-foot tool, you have to stick to ssh built-in chroot, which in turn is restricted to user's home directory (%h)= or anything else you can specify in sshd_config. At least I didn't find a way to set chroot directory in authorized_keys file, which would resolve this problem.

So it all depends on what you mean with "I don't want to create linux users for each of them". If you just don't want a /etc/passwd entry, you might one of the ways PAM is able to authenticate "virtual" users for you. You can use a database (overkill for 10 users of course), use an additional passwd-like file, berkley db files e.g. These virtual users may be restricted to service sftp or whatever you want. If their virtual home directories are set to your intended subdirectories of user backup_user, maybe this is what you want. Well - nearly. If you specify a command in authorized_keys, sftp will ask for password - I guess you don't want that.

If each of your 10 users uses 2 ssh keys, one for scp and one for sftp, this will work. You have to mimic the behaviour of the remote scp behaviour, though, specifying a script in authorized_keys file, which reads the environment variable SSH_ORIGINAL_COMMAND. A bit fiddly anyway.


ssh does not support virutal users. this can be implemented through PAM, but need to write code.

if you can add local users, you can try this tool


It jails a user into a specific directory.

  • Hi Nick, please tale a look here
    – bummi
    Sep 19, 2017 at 7:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.