Tuesday 23 Jul 2024

Mount shares using SSH

Image copyright

I heard about SSHFS from one of the Linux podcast shows. It’s a tool to easily mount a network share over the SSH File Transfer Protocol.

I wanted to play around and ended up loving it: I have removed Samba from my network (one less package to worry about).

I followed this Digital Ocean tutorial but the system will not boot unless I use _netdev in the line (Linux Mint; I did not dare attempt without _netdev on my backup server, which is Ubuntu server so may or may not work without).

If you mount as root, you need to allow other users. In the fstab command, I added allow_other, but first you need to enable this options. Edit the SSHFS config and enable user_allow_other option.

nano /etc/fuse.conf

Here’s the full line I added to my fstab for your reference:

nano /etc/fstab

sshfs#karl@192.168.1.1:/directory /home/karl/Documents fuse _netdev,defaults,identityfile=/home/karl/.ssh/id_ed25519,port=22,gid=1000,uid=1000,allow_other 0 0

Here’s why I like it so much:

It is easier to mount with existing SSH keys pair, whereas on Samba I was using log-in credentials. I used the latest ed25519 algorithm, which works well and is far more secure then using log-in credentials.

I already had a private-public key pair, but this how would have created a new one:

ssh-keygen -t ed25519

By default, keys are stored:

/home/user/.ssh/ed25519
(the private key – keep secure and secret)

/home/user/.ssh/ed25519.pub
(the public key – can be shared publicly)

Although ed25519 algorithm is new (over 5 years supported by OpenSSH), it has a few great features I liked:

• Smaller key lengths
• More secure and collision resilient
• Faster to generate and verify

Go to the ed25519.pub file and copy the public key and paste to a new line on the authorized_key file:

nano /home/user/.ssh/authorized_keys

I only have one Windows machine, so it was nice to use something native to all my Linux machines.

I was able to mount within the home directory because I wanted flatpak applications to access this directory; I could do this with Samba too, but felt like explaining.

File and directory permissions on Samba was a nightmare, but with SSH permissions are inherited from the user who logged in with the key. I am using the same user to access shell terminal so I know everything will work flawlessly, whereas on Samba I had to create another user and mess around with 777 or nobody:nogroup to make things work.

I did not need to create a new key pair. I was able to use the same key pair I used to access the terminal to mount the file share.

I have also completed these steps on Windows, but it’s a little trickier. You need to grab a few GitHub repos. Follow their GitHub instructions, but essentially install both packages and open the GUI manager (you need this to use SSH keys) and add connection, complete IP and user, then select private key location.

If you have not already set up an SSH public-private key pair, then follow these instructions.

Security considerations

• I have disabled SSH password log ins, so only accessible via a private SSH key.
• If you want to mount a backup location, make sure you specify read only (backup servers should pull from primary server, not allow primary server to push to backup)
• You can log in with a user and inherit their permissions; so you do not need to create seperate Samba users.
• Change the default port (22) to something else. Remember to enable firewall and allow the new port through. I achieved this with UFW. For example, use port 212 or 222 or 2020 whatever you like. To do this, edit the SSH config file with the new port, allow through firewall and restart SSH server.
• I used ed25519 as it’s more secure and faster to work with
• If you are using DSA or RSA (1024-bit) then these are considered unsafe and you need to upgrade to either the RSA 3072- or 4096-bit length or use ed25519.