I want to allow some trusted users to scp files into my server (to an specific user), but I do not want to give these users a home, neither ssh login.

I'm having problems to understand the correct settings of users/groups I have to create to allow this to happen.

I will put an example;


  1. MyUser@MyServer
  2. MyUser belongs to the group MyGroup
  3. MyUser's home will be lets say, /home/MyUser
  4. SFTPGuy1@OtherBox1
  5. SFTPGuy2@OtherBox2

They give me their id_dsa.pub's and I add it to my authorized_keys

I reckon then, I'd do in my server something like

useradd -d /home/MyUser -s /bin/false SFTPGuy1 (and the same for the other..)

And for the last, useradd -G MyGroup SFTPGuy1 (then again, for the other guy)

I'd expect then, the SFTPGuys to be able to sftp -o IdentityFile=id_dsa MyServer and to be taken to MyUser's home...

Well, this is not the case... SFTP just keeps asking me for a password.

Could someone point out what am I missing?

Thanks a mil,


[EDIT: Messa in StackOverflow asked me if authorized_keys file was readable to the other users (members of MyGroup). Its an interesting point, this was my answer:

Well, it wasn't (it was 700), but then I changed the permissions of the .ssh dir and the auth file to 750 though still no effect. Guess it's worth mentioning that my home dir ( /home/MyUser) is also readable for the group; most dirs being 750 and the specific folder where they'd drop files is 770.

Nevertheless, about the auth file, I reckon the authentication would be performed by the local user on MyServer, isn't it? if so, I don't understand the need for other users to read it... well.. just wondering. ]


Before you try this read all the way to the bottom please.

You can do what you want to do by creating 2 users putting them in the same group and giving them the same home directory. Then create the ~/.ssh/authorized_keys file in the shared home with the keys in.

The accounts have to have a shell so lock them using usermod -L LOGIN which will prevent interactive login.

The permissions on the ~/.ssh directory need to be g:r-x and the ~/.ssh/authorized_keys needs to be g:r--

chmod g+rx ~/.ssh
chmod g+r ~/.ssh/authorized_keys

This then causes sshd pain as it expects the directory to be at most g:r-- and the file to be g:--- you get the error message

Authentication refused: bad ownership or modes for file /home/test/.ssh/authorized_keys

To make this scheme work you now have to break sshd's inbuilt checks by editing /etc/sshd_config and setting StrictModes no from the default StrictModes yes. Restart sshd to make the changes known.

It should work as you want. Unfortunately you've taken the safety off sshd and could make changes at at later date that leave your system wide open.

To do this more securely don't make any of the changes above

Create 2 user accounts in the same group and setup their ~/.ssh/authorised_keys Create a link from each home directory to the place you want them to put stuff.

ln -s -n /path/to/stuff content

Lock down the permissions on the home directory to prevent the users writing to them.

Stop the accounts from logging in interactively

usermod -L LOGIN

Change the permissions on the /path/to/stuff to allow group access.

  • HI, it has been a while. Thanks for the answer, although it looks coheerent for me, I didn't get to try it. I will mark this as answer anyways. Thanks again!
    – filippo
    Sep 17 '10 at 8:59
  • Solution 2 shouldn't work because Symlinks are purely symbolic: they contain nothing but a path, so when you open a symlink, the OS reads the path and uses that instead. In a chroot environment, links (especially ones with absolute paths) typically don't point to the same place they pointed to in the normal environment..
    – TCB13
    Dec 9 '18 at 16:00
  • However mkdir -p content; mount --bind /path/to/stuff content works just fine with this group approach. Don't forget to add it to fstab to survive reboots.
    – TCB13
    Dec 9 '18 at 16:06
  • And be careful about running rm -rf on the mount point. This will delete all the file in the source as well. You need to always unmount before running rm or maybe one can run rm --one-file-system.
    – TCB13
    Dec 9 '18 at 16:33

It appears you want to provide access to a userid which acts as a dropbox for files. You can restrict what the users can do in the authorized keys file.

As you only want them to connect to this user id on the server, you can provide them with a .ssh/config file which maps them directly to the correct userid.


The answer to this question - How can I create a user account that only allows for uploads via sftp? - recommends a package called scponly - I've never used it, but it sounds like it might do what you want.


You may have issues with sshd (and hence sftp) not liking the permissions of the authorized_keys file.

You might be able to get away with unsetting "StrictModes" in sshd - but I'm not sure at the moment what the other implications of that setting are ...

Quoting question 3.14 in the openssh FAQ :-

Typically this is caused by the file permissions on $HOME, $HOME/.ssh or $HOME/.ssh/authorized_keys being more permissive than sshd allows by default.

In this case, it can be solved by executing the following on the server.

$ chmod go-w $HOME $HOME/.ssh $ chmod 600 $HOME/.ssh/authorized_keys $ chown whoami $HOME/.ssh/authorized_keys

If this is not possible for some reason, an alternative is to set StrictModes no in sshd_config, however this is not recommended.

Hope that helps.

  • Hmm... I don't think that's quite the case.. :( the usual ssh authentication via id_dsa will work just fine. i.e. if from one of the other boxes I do ssh MyUser@MyServer It will login pass-less just fine (same for sftp). It has to be something with SFTPGuy1's permissoins @ MyServer...
    – filippo
    Jun 4 '10 at 9:40
  • Sorry mate, I don't really get what you mean... hardlinks from where to where? what do you want to know about bt .ssh/config?
    – filippo
    Jun 4 '10 at 10:06

inspecting the log files might help. Please enter the following after an "unsuccessful" login

tail -n 50 /var/log/secure

and post the output


Could this be an option ? I'm not sure I understand your problem perfectly right but I'm pretty sure you can't SFTP if your user has /bin/false shell.


I think the most direct route is for you to grant each user an account, but set it up with the rssh (restricted) shell instead of a normal shell like bash or ksh. It's a pseudo-shell used with OpenSSH and is designed to only allow operations like scp, sftp. You can read the man page for a full description. You could then setup the target system, groups and any "drop" directories to be as locked down as you'd like (e.g. "one-use" groups, chroot jail, etc.).


Just skimming the contents, it seems like one solution would be to generate and distribute keys for each particular context. On the destination host, you can put limits on what each key can do in the authorized_keys file including the command. This can be found in the man page for sshd_config.

The example it provides is: (sorry about the formatting)

An example authorized_keys file:

    # Comments allowed at start of line
    ssh-rsa AAAAB3Nza...LiPk== user@example.net
    from="*.sales.example.net,!pc.sales.example.net" ssh-rsa
    AAAAB2...19Q== john@example.net
    command="dump /home",no-pty,no-port-forwarding ssh-dss
    AAAAC3...51R== example.net
    permitopen="",permitopen="" ssh-dss
    tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...==

I don't think there's a direct easy way to do this because of the strict permissions that sshd enforces, but would it work to set them up using ssh chroots all pointing to the same place? This would also prevent them from being able to really interact with the system if they ssh instead of scp/sftp.

  • Am I completely incorrect? Anyone care to comment on the downvote?
    – Daenyth
    Jun 9 '10 at 13:25

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.