6

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;

Having:

  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,

f.

[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. ]

9 Answers 9

4

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.

4
  • 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, 2010 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, 2018 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, 2018 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, 2018 at 16:33
1

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.

1

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.

0

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.

2
  • 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, 2010 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, 2010 at 10:06
0

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

tail -n 50 /var/log/secure

and post the output

0

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.

0

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.).

0

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== [email protected]
    from="*.sales.example.net,!pc.sales.example.net" ssh-rsa
    AAAAB2...19Q== [email protected]
    command="dump /home",no-pty,no-port-forwarding ssh-dss
    AAAAC3...51R== example.net
    permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-dss
    AAAAB5...21S==
    tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...==
    [email protected]
-1

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.

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

You must log in to answer this question.

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