Access nextcloud via SSHFS

Discuss Advanced use case
1

Hi all,

I have no problems accessing Nextcloud files in a filebrowser, in Dolphin for example via
webdavs://username@server.tld/nextcloud/remote.php/dav/files/username/

Not all programs speak WebDAV (Digikam in particular for me), so I hoped to use SSHFS. The security is too good for me to find a way in though ;-(

I added my public key to /home/users/nextcloud/.ssh/authorised_keys , but I can’t manage to log in. The id_rsa-key is not tried for user nextcloud, even though it works for admin.

Trying to log in …

ssh nextcloud@server.tld -i .ssh/id_rsa -vvv

… gives

....
debug1: Offering public key: .ssh/id_rsa RSA SHA256:pUgXalgQdsgUXF0ZFNlosixUdlumC7GTCA63+vafXyk explicit
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
nextcloud@server.tld's password:

Without explicit key, id_rsa is skipped (not tried at all, it starts with id_dsa and then a bunch of other algorithms).

In /etc/ssh/sshd_conf I found

Match User admin,root
    AllowTcpForwarding yes
    AllowStreamLocalForwarding yes
    PermitUserRC yes

Adding nextcloud didn’t seem a very good idea, but after testing, it did not make a difference so I removed it again.

I’d be hesitant to use admin or root for SSHFS-access to nextcloud, but it does not give access to nextcloud data anyway (admin has very limited access to other users’ data, root some more, but not to nextcloud data).

I am quite sure it has to do with user nextcloud not having a shell, is that correct?

Is there a workaround?

For me the best scenario would be to have SSHFS-access on a per user basis, but because it is only for private use, giving everyone access to other users nextcloud data is also an option (hence testing with sshfs nextcloud@server.tld:/home/yunhost.app/nextcloud sshfs-dir )

(Solution: ljf gave the shape of the solution, see below for FACL specifics)

2

I tried some other ways, without success.

The users home directories show up in Nextcloud, and for at least one user I can use SSHFS to mount the home directory.

  • One option was to mount the home directory (from Yunohost on the local machine) and have it show up in Nextcloud. It would, but only after rescanning the disk for changes. I mostly want to enable read access, not write access, so this is the wrong way around.
  • Another option was to symlink the users’ data from /home/yunohost.app/nexctloud/data/user/files to that users /home/user/files. That is the right direction (would give read access to the files) but that gives an inaccessible symlink.

Any suggestion?

3

What about webdavfs instead ?

SSHFS on nextcloud files means files need to be synchronized with nexcloud command line. So it won’t be done in instant…

In more, giving access to “nextcloud” user in ssh (could be done by adding it to the “app.ssh” group) seems a bit dangerous (but root or admin is worst). The good way for a ssh fs, should be to create a dedicated user, with FACL access to /home/yunohost.app/nextcloud/data and to add the ssh permission to this user).

1 Like
4

Hi ljf,

Thank you for your complete and helpful answer!

WebDAV vs SSHFS:

  • Though I didn’t make measurements, SSHFS’ response feels snappier than WebDAV
  • While both can be mounted on a directory using fstab or systemd, SSHFS can be mounted directly and integrate seamless in a directory. Quite a few programs don’t see WebDAV links as a directory, and refuse to open it as such.
  • Partly lazyness :flushed: For WebDAV I have to figure out how to put it in fstab/systemd

Files will mostly be read from those directories (photo’s), and writes don’t need to be available in Nextcloud (that will be sidecar files and EXIF info; Nextcloud does not filter on EXIF or other tags so it won’t be missed).

I haven’t used FACL before, so that is new territory. Does this sound reasonable?

  1. Add a per-user sshfs shadow user, that account does not have any Yunohost apps, but will be part of the app.ssh group, for example wbksshffs
  2. Add a group, for example sshfsrw
  3. Add a default rw FACL policy on each of the nextcloud/data/username/files directories for the sshfsrw group
  4. Add SSHFS mounts to the local systems of those users, that mount their own nextcloud/data/username/files/ directory

Even though those users won’t have Yunohost apps, I think it is good to use the Yunohost-services for user and group creation, is that correct?
I can’t find how to explicitly add a group to a default ACL without replacing the current ACL, is it safe to use ‘+rwx’ for the new group?

sudo setfacl -dR g:sshfsrw:+rwx /home/yunohost.app/nextcloud/data/wbk /files/
5

If there are “yunohost user”, the good way is to add the “SSH” permission from webadmin: webadmin > Users > Manage group and permissions > Create your group and add SSH permission in it. The group “app.ssh” is here only for apps (not users) like gitlab or others that needs an ssh access.

6

Is SSH for users a built in permission that I have to enable? I created new users and added them to a new group, but the only permissions available are the installed apps.

SSH already is installed of course, but it is not available in the list of selectable permissions in the web/admininterface.

7

Are you on an old version of yunohost ? Have you run migrations to get the SSH permissions ?

1 Like
8

I didn’t think it would be old, let me check. It is now:

Server is running YunoHost 4.1.7.2 (testing)

    yunohost version: 4.1.7.2 (testing)
    yunohost-admin version: 4.1.4 (testing)
    moulinette version: 4.1.4 (testing)
    ssowat version: 4.1.3 (testing)

Migrations:

Pending migrations
No pending migrations
Previous migrations
19. Extend/rework the app permission management system
18. Migrate old network traffic rules to the new nftable system
17. Migrate databases from PostgreSQL 9.6 to 11
16. Migrate php7.0-fpm 'pool' conf files to php7.3
15. Upgrade the system to Debian Buster and YunoHost 4.x

Updates:


ssowat (from 4.1.3 to 4.2.4)
yunohost-admin (from 4.1.4 to 4.2.5)
yunohost (from 4.1.7.2 to 4.2.8)

Ah, there I am behind! Since when is the SSH permission available? I’ll run the update immediately!

-Edit-
Upgrade, so I thought. I’m still on packages.sury.org with this Yunohost, so it is not able to update. I have to look up what the workaround for that was; brb :slight_smile:
(slightly off topic, for those with the same problem:

apt-key del B188E2B695BD4743
apt-key adv --keyserver keys.gnupg.net --recv-keys B188E2B695BD4743
curl -sSL -o /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg

Not all may be necessary, but without apt-key del it may go wrong, and just apt-key adv may not find the key. If it does not work: check the key ID)

9

Yes, that was it. After upgrading I can assign the SSH permission. Nice warning about attack surface, no manual migration needed.

Now it works!

FACL gave me some trouble; first I did

setfacl -dRm g:sshfsnc:rwx /home/yunohost.app/nextcloud/data/wbk/files/

for all my user’s data, but it turns out that the group sshfsnc I made in the admin interface, is not propagated as a system group (or membership is not propagated).

After setting FACL for the specific user (recursively behind …/wbk/files, directory by directory for the parent path), I could cd to the files.

setfacl -Rm u:wbknc:rwx /home/yunohost.app/nextcloud/data/

Take note: future ACL’s are applied by using -dRm, but current ACL’s are not applied by changing the default (with -d), so you need to use -dRm as well:

setfacl -dRm u:wbknc:rwx /home/yunohost.app/nextcloud/data/

Thanks a lot!