[IDEA] allow sshfs mount remote storage (rights access issue solved for sshfs)

[Phil35]

Hi,

Today only SMB and NFS are allowed to mount remote storage.

It would be nice to allow sshfs. It uses SSH,  avoid  SMB and NFS.
sshfs - filesystem client based on SSH File Transfer Protocol

# dpkg -l sshfs
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version        Architecture Description
+++-==============-==============-============-=====================================================
ii  sshfs          3.7.1+repack-2 armhf        filesystem client based on SSH File Transfer Protocol

example:
sshfs -p xxxxx   user@ip:/remote/dir   /local/dir

Thank you
Phil

[Tim Curtis]

What are the advantages of SSHFS compared to Samba and NFS?

[TheOldPresbyope]

Quoting from Wikipedia:

Features

SFTP provides secure file transfer from a remote file system. While SFTP clients can transfer files and directories, they cannot mount the server's file system into the local directory tree. Using SSHFS, a remote file system may be treated in the same way as other volumes (such as hard drives or removable media).

Using the Unix command ls with sshfs will sometimes not list the owner of a file correctly, although it is possible to map them manually.

For distributed remote file systems with multiple users, protocols such as Apple Filing Protocol, Network File System and Server Message Block are more often used. SSHFS is an alternative to those protocols only in situations where users are confident that files and directories will not be targeted for writing by another user, at the same time.

The advantage of SSHFS when compared to other network file system protocols is that, given that a user already has SSH access to a host, it does not require any additional configuration work, or the opening of additional entry ports in a firewall.

This may seem a useful addition for dyed-in-the-wool LInux-heads; for everyone else, not so much. Since I have other players which use Samba I'm not particularly interested.

Regards,
Kent

[Phil35]

Hi,
Working with linux platforms ssh is by default installed and configured.
Can also be installed and configured on Windows with SSHFS-Win.

Why should more protocols needed?

No need to have others protocols with for some security issues as SMB has, and several versions (SMBv1, SMBv2, SMBv3) as SMB has again ...
same for NFS v2, v3, v4

So this is simpler and more secure.

Phil

[the_bertrum]

So this is simpler and more secure.

But also less ubiquitous and isn't "ready to go" on as many devices. I think it would be a mistake to add this at the expense pf the more widely known and popular options, even if it is inherently better. It would be akin to dropping MP3 because AAC is better.

[Phil35]

Hi,
Adding an option do not mean removing the current ones.
Adding an option gives another way to access to storage
It is more choice for all

Phil

[Tim Curtis]

So this is simpler and more secure.

But also less ubiquitous and isn't "ready to go" on as many devices.  I think it would be a mistake to add this at the expense pf the more widely known and popular options, even if it is inherently better. It would be akin to dropping MP3 because AAC is better.

Hi,
Adding an option do not mean removing the current ones.
Adding an option gives another way to access to storage
It is more choice for all

Phil

Both points are valid. 

The issue for me is that since each option in moOde creates a vector for support any new option that is added has to be considered in that context and for reference mounting remote storage is one of the top issues as far as support goes.

Also adding a new mount protocol involves adding it to the File Sharing options and the Mount Monitor which means learning how to detect SSHFS failure modes. All said not a trivial amount of work.

[Phil35]

ok
I made a test
first: backup of /mnt/SDCARD
with command:
cd /home/pi
tar -C /mnt -cvf moodeaudio.SDCARD.tar  ./SDCARD
./SDCARD/
./SDCARD/Stereo Test/
./SDCARD/Stereo Test/LRMonoPhase4.flac

then sshfs mount:
sshfs -p 54321 -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3 philippe@192.168.6.237:/music /mnt/SDCARD
philippe@192.168.6.237's password:

cd /mnt/SDCARD
df -H .
Filesystem                     Size  Used Avail Use% Mounted on
philippe@192.168.6.237:/music  3.0T  2.1T  898G  70% /mnt/SDCARD

I also tried to mount in "/mnt/SDCARD/Stereo Test"
It seems working as I read in the log:
20230118 162744 thumb-gen: Scanning: NAS, SDCARD
20230118 162747 mpdindex: Done: indexed 1077 artists, 504 albums, 6946 songs
20230118 162747 worker: Job update_library done
20230118 162753 worker: Job update_library
20230118 162753 mpdindex: Start
20230118 162753 mpdindex: Cmd (update "SDCARD/Stereo Test")
20230118 162757 mpdindex: Done: indexed 1077 artists, 504 albums, 6946 songs
20230118 162757 worker: Job update_library done

However nothing on the screen .. click on "SDCARD" shows nothing.

Phil

[TheOldPresbyope]

So this is simpler and more secure.

But also less ubiquitous and isn't "ready to go" on as many devices.  I think it would be a mistake to add this at the expense pf the more widely known and popular options, even if it is inherently better. It would be akin to dropping MP3 because AAC is better.

Hi,
Adding an option do not mean removing the current ones.
Adding an option gives another way to access to storage
It is more choice for all

Phil

Both points are valid. 

The issue for me is that since each option in moOde creates a vector for support any new option that is added has to be considered in that context and for reference mounting remote storage is one of the top issues as far as support goes.

Also adding a new mount protocol involves adding it to the File Sharing options and the Mount Monitor which means learning how to detect SSHFS failure modes. All said not a trivial amount of work.

There's almost 50 optional parameters to sshfs, many of which I believe can be ignored without causing anyone any heartburn (but we LInux-heads do love our options ) 

Certainly, it works for me to mount a remote directory from one of my Linux boxes in moOde's /mnt/NAS tree using sshfs with minimal options to allow others to access the directory besides its owner.

A big concern to me, though, is the very security aspect which was emphasized by the OP. Since this is ssh, I have to either store the username and password for the account owning the remote directory or deal with a key file. Besides the UI and bookkeeping for this, it gives a user on a moOde player the ability to log into the remote system. Once one starts working through best-practice settings for the remote system and the local sshfs options, the simplicity evaporates. At least that's the way I see it.

Just my 2-cents worth. If this feature gets implemented, I'll test it.


Regards,
Kent

[Tim Curtis]

So this is simpler and more secure.

But also less ubiquitous and isn't "ready to go" on as many devices.  I think it would be a mistake to add this at the expense pf the more widely known and popular options, even if it is inherently better. It would be akin to dropping MP3 because AAC is better.

Hi,
Adding an option do not mean removing the current ones.
Adding an option gives another way to access to storage
It is more choice for all

Phil

Both points are valid. 

The issue for me is that since each option in moOde creates a vector for support any new option that is added has to be considered in that context and for reference mounting remote storage is one of the top issues as far as support goes.

Also adding a new mount protocol involves adding it to the File Sharing options and the Mount Monitor which means learning how to detect SSHFS failure modes. All said not a trivial amount of work.

There's almost 50 optional parameters to sshfs, many of which I believe can be ignored without causing anyone any heartburn (but we LInux-heads do love our options ) 

Certainly, it works for me to mount a remote directory from one of my Linux boxes   in moOde's /mnt/NAS tree using sshfs with minimal options to  allow others to access the directory besides its owner.

A big concern to me, though, is the very security aspect which was emphasized by the OP. Since this is ssh, I have to either store the username and password for the account owning the remote directory or deal with a key file. Besides the UI and  bookkeeping for this, it gives a user on a moOde player the ability to log into the remote system. Once one starts working through best-practice settings for the remote system and the local sshfs options, the simplicity evaporates. At least that's the way I see it.

Just my 2-cents worth. If this feature gets implemented, I'll test it.


Regards,
Kent

Regarding security, let's not forget that moOde is not a secure system and so some basic, common sense practices should always be followed.

1. It should only be used on a trusted network.
2. It should never be connected directly to the Internet :-0
3. The SSH logon password should be changed from the default

With that said I should also mention that Samba (SMB) userid and password if specified are stored in plaintext and NFS doesn't support userid/password security but instead grants access by host or entire subnet.

You are correct about SSHFS security only being valid if keyfile or some other method for securely storing passwords can be implemented.  Another option would be to prompt for password to initiate the mount but that goes in the opposite direction of user-friendliness.