How to mount remote file systems with SSHFS step by step

Work with files residing on a remote server as if they were on your own computer It's one of those little luxuries that, once you try it, you never want to give up. For development, system administration, or simply for having your own "home cloud," setting up remote file systems can save you a lot of headaches.

SSHFS is precisely the tool that makes this possible in a simple and secure way.Thanks to SSH and SFTP, you can mount remote directories on your local machine and treat them as if they were just another disk, without having to start additional services like NFS or Samba. In this guide, we'll take a detailed look at what SSHFS is, how it works, how to install and configure it on GNU/Linux, macOS, and Windows, and what options you have for automating and fine-tuning its behavior.

What is SSHFS and why might it interest you?

SSHFS (Secure Shell FileSystem) is a FUSE-based file system that allows mounting remote directories using SFTP.That is, the SSH file transfer subsystem. In other words, all communication between your computer and the server is encrypted, authenticated, and encapsulated within the same SSH connection as always.

Unlike other network file systems such as NFS or SAMBA/CIFS, SSHFS does not require configuring extra services on the server.All that's needed is for the server to have a running and accessible SSH daemon. The SSHFS client itself, using FUSE, will then present that remote resource as another mount point on your system.

Using SSH and SFTP means that all data is encrypted and decrypted in real time.This applies to both the server and client sides. There are pros and cons to this: on the one hand, you gain confidentiality and integrity; on the other hand, you introduce a performance penalty compared to options like NFS on trusted local networks.

FUSE (Filesystem in Userspace) is the kernel component that allows non-privileged users to create file systems "in user space".without needing to modify the kernel or load complex modules. SSHFS relies on FUSE to hook the remote file system and expose it in your local directory tree.

Common uses of SSHFS: beyond “copying four files”

Mounting a remote file system with SSHFS has countless practical uses.Many of them focus on having your "usual" data available wherever you are, with an experience very similar to working locally.

One of the most typical uses is to set up a personal cloud: a server at home or on a remote VPS where you store your documents, photos or projects, and which you access from your laptop or desktop as if it were another system disk, without having to go through third-party services.

In local networks, SSHFS is very useful for sharing data between computers. LinuxFor example, accessing folders on another computer on the network, sharing the directory tree of a powerful machine with lighter ones, or connecting Virtual machines with the host without any headaches.

For developers, it's a very convenient tool for editing code directly on remote servers. (for example, web servers or test machines) using the trusted local editor, without needing to manually synchronize with rsync, scp or similar.

It also works very well as a simple backup mechanismYou can set up the remote route and use your tools backup usual on that mount point, or vice versa, mount a remote destination to dump your backups from the local machine.

Prerequisites: what you need on the client and server

The foundation of any SSHFS setup is having an accessible SSH server and a client with FUSE support.From there, the rest is just configuration details and ease of use.

On the server side, you need, at a minimum, to have the OpenSSH service installed and running.In most modern GNU/Linux distributions, you simply need to make sure that the package openssh-server It is installed and the service is enabled:

Install the SSH server: sudo apt-get install openssh-server openssh-client

Use yum on RHEL/CentOS: sudo yum install openssh-server openssh-clients

On the client side, in addition to OpenSSH, you need the sshfs package and FUSE.In Debian/Ubuntu, for example, the command would be:

Customer packages: sudo apt-get install sshfs fuse

On Red Hat / CentOS systems you may first need to enable EPELbecause sshfs is not always in the base repositories. Once enabled:

Install sshfs: sudo yum install sshfs
or in modern versions:
Install with dnf: sudo dnf install sshfs

Check and activate the FUSE module in GNU/Linux

Before starting to assemble anything, it is advisable to verify that the FUSE module is available and active. in the kernel of your client machine, since SSHFS depends directly on it.

Check FUSE module: lsmod | grep fuse

If you see a line similar to “fuse 86016 3”, it means the module is loaded. And you can continue. If nothing appears, there are two possibilities: either the module has not yet been loaded, or FUSE is compiled directly into the kernel (built-in).

Check if it's integrated into the kernel: grep -i fuse /lib/modules/$(uname -r)/modules.builtin

If the command returns something like “kernel/fs/fuse/fuse.ko” you can rest easyFUSE is available even if you don't see it in lsmod. If you still don't get any output, then you'll have to load it explicitly.

Load module: sudo modprobe fuse

FUSE user and group permissions

Since SSHFS runs in user space, it's common for your user to need to belong to the fuse group. to avoid permission problems when mounting file systems.

In Debian/Ubuntu distributions you can use the “members” package to check which users belong to a groupFirst, you install it:

Install members: sudo apt-get install members

Then you consult the members of the fuse group with:

List of group members: members fuse

If your username is not listed, you will need to add it.For example, if your name is joan:

Add user to group: sudo gpasswd -a joan fuse

After this, it is recommended to log out and log back in for the group changes to take effect.Once you have verified that everything is correct, you can uninstall the package if you wish. members because you've only used it as a one-off check tool.

Install SSHFS on different platforms

SSHFS is available not only on GNU/Linux, but also on macOS and Windows through ports and adaptations.so you can use it in virtually any mixed work environment.

On Debian, Ubuntu and Linux Mint The installation is reduced to:

Update and install (apt): sudo apt update
sudo apt install sshfs

In RHEL, CentOS and derivativesOnce you have the necessary repositories active, you can run:

Update and install (yum): sudo yum update
sudo yum install sshfs

On macOS, the most convenient way is to use Homebrew and FUSE for macOSThe typical steps are:

Install Homebrew (if you don't already have it):
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Install FUSE for macOS:
brew cask install osxfuse

Install sshfs on macOS:
brew install sshfs

Windows does not have native SSHFS, but you can use implementations like win-sshfs or SSHFS-Win.which rely on WinFsp-type components to expose FUSE file systems as Windows disk drives.

Mounting a remote file system with SSHFS (basic usage)

The general syntax of the sshfs command in GNU/Linux and macOS is simple and quite intuitive.The usual pattern is as follows:

Command syntax: sshfs [usuario@]host:[directorio-remoto] punto-de-montaje [opciones]

First of all, you must create the directory on the client machine where you will mount the remote file systemFor example, if you want to mount the remote folder in ~/desktop:

Create mounting point: mkdir -p /home/joan/desktop

A complete example of manual assembly could be:

Example assembly: sshfs joan@192.168.1.14:/home/joan /home/joan/desktop

In this command, “joan@192.168.1.14” identifies the user and the server IP address., :/home/joan is the remote route you want to share, and /home/joan/desktop This is the local mount point where the content will appear.

If the SSH service is listening on a port other than 22, you must specify it with -pFor example, if the server uses port 24:

Custom port: sshfs -p 24 joan@192.168.1.14:/home/joan /home/joan/desktop

After executing the command, you will usually be asked for the remote user's password.Unless you already have password authentication configured. If everything goes well, a new volume associated with the mount point will appear in your file manager, and you'll be able to browse and edit the files just as if they were local.

Useful mounting options with SSHFS

SSHFS accepts a number of options that fine-tune behavior, permissions, and performance.Some of the most practical ones for everyday life are the following.

To control the mapping of user and group identifiers on the local side You can use options like:

Force UID/GID: -o uid=$(id -u),gid=$(id -g)

This forces remote files to appear as if they are owned by your local user.This prevents permission conflicts when IDs don't match between the client and server. You can combine it with options such as idmap=user when you use /etc/fstab.

To improve resilience against connection outages, it is common to use:

Automatic reconnection: -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3

Other common options are auto_cache to better manage the attribute cache, allow_other so that other users besides root can access the assembly point, and default_permissions to delegate permission control to the local kernel.

Unmounting an SSHFS file system

When you no longer need the assembly, it is important to disassemble it correctly.Especially if you've been writing data, to make sure everything has been sent to the server and there are no pending operations.

Use fusermount to dismount: fusermount -u /home/joan/desktop

Or with the classic assembly command:

Dismount with umount: sudo umount /home/joan/desktop

In many desktop environments you can also unmount the volume from the file explorer itself.by right-clicking on the mounted volume and choosing the "Unmount" or "Eject" option.

SSH key authentication for passwordless mounting

If you're going to use SSHFS regularly, it makes sense to avoid having to enter the password every time you mount it.For that, the best option is to configure SSH key-based authentication.

On the client, you generate an asymmetric key pair using ssh-keygen (without passphrase if you want the automatic assembly to not ask for anything):

Generate key: ssh-keygen -b 4096 -t rsa -C "$(whoami)@$(hostname)-$(date -I)"

-b 4096 indicates the size in bits of the key, -t rsa defines the algorithm, and the -C parameter adds an identifying comment to the key (for example, user, machine and date).

When ssh-keygen asks you where to save the key, simply press Enter to use the default path (~/.ssh/id_rsa)And you can leave the passphrase empty if you want the connection process to be completely automatic.

The generated public key (~/.ssh/id_rsa.pub) must be copied to the server and be added to the file ~ / .Ssh / authorized_keys of the remote user that you will use with SSHFS.

Copy and authorize the public key on the server

First, make sure that the authorized_keys file exists within ~/.ssh on the server.You can create it with:

Create authorized_keys if missing: touch ~/.ssh/authorized_keys

On the client, copy the public key to the server using scp or ssh-copy-id.For example, with scp:

Copy public key to server: scp ~/.ssh/id_rsa.pub joan@192.168.1.14:~/.ssh

Once on the server, add the contents of id_rsa.pub to the authorized_keys file to authorize that key:

Add key to authorized_keys: cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

After this, if the properties and permissions of ~/.ssh and authorized_keys are correctYou will be able to connect from the client to that server without entering a password, and by extension, automatically mount it with SSHFS using the option IdentityFile.

Mount SSHFS file systems automatically with /etc/fstab

If you want the remote file system to mount automatically every time the computer starts, without your intervention.You can use the /etc/fstab file to define the SSHFS mount.

On the client machine, edit the /etc/fstab file with administrator privileges:

Edit fstab: sudo nano /etc/fstab

An example of a typical assembly line with SSHFS would be:

Complete fstab example: joan@192.168.1.14:/home/joan /home/joan/desktop fuse.sshfs defaults,idmap=user,_netdev,users,IdentityFile=/home/joan/.ssh/id_rsa,allow_other,reconnect 0 0

In this line you specify the remote resource, the local mount point and the file system type (fuse.sshfs), followed by a set of options:

defaults: applies typical mounting options (read/write, exec, etc.).
idmap=user: forces the apparent owner of the files to be your local user.
_netdevThis indicates that the system depends on the network, which helps systemd manage the order of Boot.
users: allows any user to mount/dismount the resource.
IdentityFile: private key path to connect without a password.
allow_other: grants access to users other than the one mounting it (requires FUSE configuration).
reconnect: Retry the connection if it drops.

In distributions using systemd, it may be interesting to use the noauto option combined with x-systemd.automountso that the assembly is activated on first access:

Example fstab with automount: joan@192.168.1.14:/home/joan /home/joan/desktop fuse.sshfs noauto,x-systemd.automount,_netdev,users,idmap=user,IdentityFile=/home/joan/.ssh/id_rsa,allow_other,reconnect 0 0

Keep in mind that a syntax error or an incorrectly set option in fstab can prevent the system from booting normally.Therefore, it's advisable to back up /etc/fstab before touching it and have a LiveUSB handy in case you need to fix it offline.

Configure FUSE to use allow_other

The allow_other option, very useful for sharing the mount point with other users, does not work unless you explicitly enable it in the FUSE configuration..

In most distributions, it is sufficient to edit /etc/fuse.conf as root:

Edit fuse.conf: sudo nano /etc/fuse.conf

Within the file, find the line containing “#user_allow_other” and uncomment it.leaving it like this:

user_allow_other

Save the changes and close the editorFrom that moment on you will be able to use the allow_other option in your SSHFS mounts and in /etc/fstab without it being rejected by configuration.

Using SSHFS on Windows: win-sshfs and SSHFS-Win Manager

In Windows, the use of SSHFS involves third-party tools that integrate FUSE with the operating system's own file system.The two most common approaches are win-sshfs and the SSHFS-Win + WinFsp combo, often managed with a convenient graphical interface.

win-sshfs was for a long time one of the simplest optionsAn installer is downloaded that includes everything needed to mount a remote directory via SSH as if it were a Windows drive. Once installed, simply open the application, create a new entry, fill in the host, port, username, password, remote path, and drive letter, and click Mount.

A more modern alternative is SSHFS-Win along with WinFsp and, to top it all off, SSHFS-Win Manager as a graphical interfaceWinFsp acts as a layer that allows Windows to communicate with FUSE file systems, SSHFS-Win provides SSHFS support itself, and SSHFS-Win Manager offers a GUI for creating and managing mounts without touching the command line. commands.

The typical workflow with SSHFS-Win Manager is very similar to how a graphical user would do it in Linux.: You add a new connection, write the server's IP or domain, the SSH port (usually 22), your username and password or key, choose the remote path (/, /var/www, ~/… depending on your needs) and assign a drive letter so that it appears in "This PC".

Once mounted, the remote directory appears in Windows File Explorer as just another drive.And you can drag and drop files, rename, edit and delete almost as if you were working on a local hard drive.

Best practices, performance, and security with SSHFS

SSHFS is very convenient, but it's important to be aware of its limitations and some security recommendations.especially if you are going to create directories with sensitive data or work over the Internet.

In terms of performance, encryption and network latency make all the difference.On fast local networks with relatively powerful servers, performance will be reasonably good, although below that of NFS in most scenarios. Over the internet, latency can be quite noticeable in operations involving many small files.

For security reasons, mounting remote directories in production with fstab and permanent mounts is not always a good idea.Since a client compromise could open a direct door to the server, it's preferable to limit access, use chroot users, or implement highly restricted permission systems for critical environments.

It is also important to review the firewall settings and the router when you access from outside your local networkYou will need to redirect the SSH port to the machine acting as the file server, and ensure that it is only accessible from controlled sources or at least use hardening measures such as fail2ban, strong keys, and disabling password login.

Finally, if you mount root user directories or highly sensitive paths, take extreme precautions.The usual practice is to work with a user without elevated privileges and delegate delicate operations to sudo on the server itself, instead of opening the remote system's root wide open.

SSHFS becomes an incredibly versatile tool for managing, developing, and sharing data on remote servers.Especially when you already have a working SSH service and want to avoid dealing with additional NFS or Samba configurations. Used wisely, with well-managed keys and the right FUSE and fstab options, it allows you to have your remote systems readily accessible, just like any other folder on your machine, without compromising security or stability.