Proper mounting of a remote folder through SSH

[Cubytus]

Hi there,

this question may not be exactly for "beginners", but I bet my mistake must be. I have a remote server accessed through root user, whose configuration can't be easily changed. I want to mount the folder on the Pi with write-only access, and have the Pi periodically retry mounting

So I generated an RSA key pair on the Pi, then sent the public key to the server, and added the following line to /etc/fstab

Code: Select all

sshfs#root@server.org:/Data /home/pi/onetb fuse port=2222,pi,noauto,noatime,nonempty,_netdev,allow_other 0 0

expecting it to be mounted on boot, but it doesn't.

I suspect the issue has to do with different users being used on both machines, but don't know how to make them work smoothly, in an automated manner.

[DougieLawson]

You don't use SSH for remote mounts.

You use NFS (preferred) or Samba (if the share needs to be used by windows).

So, sorry but I don't understand what you're trying to do.

[DirkS]

You don't use SSH for remote mounts.

OP is using sshfs: https://wiki.archlinux.org/index.php/sshfs

Gr.
Dirk.

[DougieLawson]

You don't use SSH for remote mounts.

OP is using sshfs: https://wiki.archlinux.org/index.php/sshfs

Gr.
Dirk.

Then this thread shouldn't be in "Beginners" because that is weird s***.

[pluggy]

I use remote mounts on my Pi from a Ubuntu machine all the time. Standard Nautilus (file manager) will mount any ssh available folder (or at least make it look and work like it is). Its a bit more trouble if you're using that crippled Redmond OS I can never remember the name of.....

[Cubytus]

There is no Windows machine implied anywhere here, and NFS or Samba don't cut it over the Internet. There's no implication of reliability, hence the periodic reconnection attempt if mount disappears. SSHFS isn't that advanced, and I'm nowhere near an expert, hence the presence of this question in "beginners".

So what is the proper call to mount the remote folder in fstab?

[jojopi]

sshfs is great for ad-hoc mounting because it needs no setup, does not require root privilege on either client or server, and is inherently quite secure and difficult to misconfigure.

It is not good for system-level mounts, however.

So I generated an RSA key pair on the Pi, then sent the public key to the server, and added the following line to /etc/fstab

sshfs#root@server.org:/Data /home/pi/onetb fuse port=2222,pi,noauto,noatime,nonempty,_netdev,allow_other 0 0

expecting it to be mounted on boot, but it doesn't.

The "noauto" option specifically means not to mount the filesystem on boot. The "pi" option does not exist, and that is fatal. The mount happens as root, so it is root who needs to ssh-keygen and ssh-copy-id.

"allow_other" is a really bad idea. The permissions models at the two ends of the connection may be wildly different, and sshfs makes no attempt to translate between them. Instead, the thing that makes it safe normally is that it denies all access except to the user who performed the mount—the user who has the password or key to the remote system anyway. You are trying to give every user on the client root access on the server!

I think you are actually better off with no fstab entry at all. Just run as pi: "sshfs -p2222 root@server:/Data ~/onetb" until it works. I would fix the permissions on the server first so that it does not need root.

For automatic reconnection you will need some background hack that detects the failure and retries. It may need to lazy umount and even kill afflicted processes first. Either way, anything accessing the mount when it fails will probably crash.

I suspect if you search you will find that sshfs automatic reconnect hacks have already been written, but I cannot personally vouch for any of them.

By the way, what is "write-only access"?!

[Cubytus]

Thanks for these details. I followed a few tutos, but there were many uncommented parameters. Write-only is exactly that, permissions 330 or 333, as for this application, if an intruder gained access to the Pi, he wouldn't be able to delete files, worse than writing bogus ones. Or perhaps less paranoid, a misconfiguration on the Pi wouldn't allow me to accidentally erase files. As I said, the server is a very fragile configuration I can't easily change, otherwise I would have made a chroot with a new user "pi" on it. By default, only root has access through SSH, also the reason why I chose a long and hard password and non-default port. If I break the configuration, there's no easy way for me to recover as the server is miles away.

I thought the "pi" flag would allow user pi to be the owner of the mounted folder. I did try a manual mount before without specifying user, and ended up with unknown permissions, making the folder inaccessible unless using root. Probably what you point with

sshfs makes no attempt to translate between them

.

I want only user pi to have root access to the server, the reason why I assumed I had to ssh-keygen and ssh-copy-id from user pi, but on the other hand, automated mount is done through fstab being executed as root. Would I need to put this mount call in pi's init.d, then, instead of system-wide fstab? Wouldn't that cause issues if the applications used to write in the mounted folder run as a different user than pi? Of course I can mount it manually with correct permissions, but this isn't what I want to do. It must be automated and self-recovering. If the writing application crashes if ever the mount is unavailable, then it may be simpler to have the script reboot the RPi.

[jojopi]

Write-only is exactly that, permissions 330 or 333, as for this application, if an intruder gained access to the Pi, he wouldn't be able to delete files, worse than writing bogus ones.

Since this is in Beginners, I must remind you that you only need write+execute permission on a directory to delete all its files (regardless of the permissions on the files themselves). However, perhaps you mean that without read access you can only delete files whose names you can specify. So it would thwart attacks like "rm *" and "rm -rf".

I thought the "pi" flag would allow user pi to be the owner of the mounted folder. I did try a manual mount before without specifying user, and ended up with unknown permissions, making the folder inaccessible unless using root.

sshfs is just a fuse interface to sftp. The permissions on the server for the user that ssh authenticated as are the ones that matter. If you authenticate as root, you have all permissions.

You can set the local (numeric) owner and group and masked permissions with "uid=N,gid=N,umask=0N", but these are basically cosmetic. Normally they are not even checked. If you also set "default_permissions", then they will be honoured locally before the remote permissions come into play. That is not really increasing security, though. The user who owns the private key file can just remount without the options.

If you do want to try to add restrictions at the client end, then it probably is better to have root own the ssh key and set the local permissions to allow pi only, rather than let pi own the key. If you mount as root then you will need "allow_others", so you must combine that with some sensible local restrictions.

There is an option "reconnect", but in brief testing I have not found it to work well.

Apart from a hack to kill and restart sshfs when necessary, another option would be to mount sshfs via autofs. That attaches it when accessed and unmounts when inactive. If the filesystem is only used occasionally it may be more reliable because it does not keep ssh connections open for very long periods. If the filesystem is in continuous use, autofs will not help.

Just because you only have ssh access to the server does not mean that you have to use sshfs. You could tunnel nfs or cifs over ssh also. That does not help with connection reliability, however. Do you need direct filesystem-based access at all?

[Cubytus]

Since this is in Beginners, I must remind you that you only need write+execute permission on a directory to delete all its files (regardless of the permissions on the files themselves). However, perhaps you mean that without read access you can only delete files whose names you can specify. So it would thwart attacks like "rm *" and "rm -rf".

Indeed I probably made a mistake. Technically the permissions would be 220, but I know there is some usage for the "execute" flag that has no link with running programs out of the directory. But it seems there is no perfect solution to keep files from being deleted through a connection to the server, as it gives unrestricted access through root.

sshfs is just a fuse interface to sftp. The permissions on the server for the user that ssh authenticated as are the ones that matter. If you authenticate as root, you have all permissions.

Technically no. I wasn't able to cd into the mounted folder on the Pi under user pi. How would I translate the server's permissions and ownership in a way to make it writeable-only from user pi?

If you do want to try to add restrictions at the client end, then it probably is better to have root own the ssh key and set the local permissions to allow pi only, rather than let pi own the key.

But AFAIK Raspbian doesn't have user root. How would it be done?

There is an option "reconnect", but in brief testing I have not found it to work well.

Apart from a hack to kill and restart sshfs when necessary, another option would be to mount sshfs via autofs. That attaches it when accessed and unmounts when inactive. If the filesystem is only used occasionally it may be more reliable because it does not keep ssh connections open for very long periods. If the filesystem is in continuous use, autofs will not help.

Well I expect the remote folder to be written continuously in a worst-case scenario. So accounting for the network lag, perhaps it would be more reliable to first write it to a local directory, then copy its content to the remote folder?

Just because you only have ssh access to the server does not mean that you have to use sshfs. You could tunnel nfs or cifs over ssh also. That does not help with connection reliability, however. Do you need direct filesystem-based access at all?

I am not sure I get your last question.

Tunnel is a solution, but the RPi has limited power, and may not be able to perform write-intensive tasks and maintain a tunnel at the same time. With sshfs, the Pi would use only one protocol, as opposed to two if I were to tunnel another protocol through it. I also had a question about the lightest protocol on the CPU choosing between Samba, NFS and AFP, but so far have received no answer on this precise point. I also read that NFS, while simple, had a tendency to crash the client whenever the share becomes unavailable, probably the reason why it isn't recommended.