I turned on SFTP tonight and added an SFTP share. To my surprise, my SFTP client started out in the users home directory instead of the share. Also, I could browse almost everywhere on my system. I deleted the SFTP share and was still able to connect and do almost anything. The good news is that when I turned the SFTP service is off, the client cannot connect.
@sudowoodo thanks for starting this topic. I’d like to understand your setup in more detail to reproduce the behavior. Here’s my simple test so far.
- I have a share called
sftpshareowned by the useradmin. - sftp service is turned on.
-
sftpshareis exported via sftp
- I also have a bunch of other shares on the system, but none of them are exported via sftp as you can see.
- on the client side, i am testing with my ubuntu laptop using the
Filesprogram. - this is what i see after the client is authenticated.
- You are right that the client doesn’t go to the inside of the share, but rather a chroot directory that has minimal set of tools needed for sftp to work along with any shares that were exported and owned by the user.
Can you please provide more details so we can reproduce what you are seeing?
@suman thanks for your response. I have SFTP turned on with no shares created.
I then use AndFTP from my Android phone to connect to my device running Rockstor (RockBox)
This is what I see when the client is authenticated:
from there I can access parent directories all the way up to /
I can also upload files to shares that the user has permissions for:
If you need any more information, I will be happy to provide it.
Great detail, thank you. Can you try this? Pick a Share that is owned by the user brandon and export it via SFTP. Then use AndFTP like you demonstrated and let’s see if it makes any difference.
That does change things. I see the same 4 folders that you see after you are authenticated.
Hi, this is correct behaviour because you have not created the sftp user and group for the share and set permissions, you really should work with users and groups and set permissions on the share by Access control owner and group. When you set the permissions/rights as required, you won’t be able to walk all the way up in the three.
You will always end up seeing the folders required for your login environment [/bin/bash or /sbin/nologin]
Best would be nothing is open for any user, you don’t want any user be able to go everywhere, I don’t think any other NAS does allow that, I know for sure Openmediavault is locked down. I prefer all is locked down and I need to create groups/users.
My question is, what is the desired behavior from Rockstor?
Should we allow ssh for all users by default? (current implementation)
Does it make sense to restrict ssh access to only a certain group, say an admin group?
Should we provide an ssh access toggle during user creation?
From what I am seeing, currently an SFTP share can only be accessed by the owner of the share. Any other user can explore the entire system. Is this what it was designed to do? Personally I would prefer to turn on SFTP per user. I don’t want to have to create personal SFTP shares for all users. Does this make sense?
Edit:
I want to make it clear that if I make an SFTP share that Brandon is in the group, but not the owner, the results will be the same as in my second post.
@sudowoodo @suman Yeah, that is not good, it should all be no access, like OpenMediaVault or any other NAS system. I am so used of creating users and groups I did not even check that out… thanks for letting me know.
Ok, I’ve changed the behavior as of 3.8-7 as follows:
- By default, only root can ssh.
- When a Share owned by a user is exported via sftp, that user can also ssh/sftp and is put into a chroot where only Shares owned by that user are visible.
- Apart from the above, non-root users cannot ssh into the box.
I’d be happy to improve this further. If there’s something I overlooked or a better way of doing things, please make your case.
Hi Suman!
I confirm the working behaviour for 1 and 3 as you stated above. But 2 does not work. The login is denied after three tries with correct passwords. I tested with three different users and four different shares. My Rockstor box is running 3.9.2-13. I’m using an Ubuntu 16.04.3 LTS laptop as client.
I am using the latest OMV. I have run into the same issue. I have installed the SFTP, created a share, and created a user. added the user to the SFTP Group. When I use FileZilla to connect to the share, I see the entire OMV directory instead of the share only. Is it possible to fix this so that it only works like a regular share other than the security side of it? I want to have protected access for communication but do not want anyone seeing the entire directory.
Hi @mathewaowens welcome to the Rockstor community. I assume, you are not running Rockstor as part of your setup? In any case, if you look at the Rockstor documentation for sftp, there is a use of the chroot concept to isolate a share exposed for sftp consumption:
https://rockstor.com/docs/interface/storage/file_sharing/sftp.html
I don’t use OMV, however I did find a forum post (a few years old, so not sure it’s been more simplified since then) that configures the sftp using chroot:
You will probably have to dig in some more over there, as further down in that thread it mentions some fixes/changes in that space.
And, when browsing the documentation, in the latest version you will see that there is some more configuration required to set up a jail for sftp shares, so that might be the part you’re missing:
https://docs.openmediavault.org/en/stable/administration/services/ftp.html
Good luck!
1 Like