1. Overview
SSH is one of the most common remote access protocols. It’s widely used in many environments, even outside Linux and UNIX. Because of this, it has become the basis for other functions, providing a secure platform for extended features.
In this tutorial, we’ll look at how to mount a remote directory locally in Linux using the sshfs tool.
2. sshfs
sshfs is a Linux command-line tool that enables us to mount a remote directory locally. Once mounted, users can interact with the mount point as if the remote directory contents exist on the local filesystem.
Behind the scenes, sshfs uses the SFTP protocol to carry out any necessary file transmission between the two nodes. Therefore, the remote server must be running sshd and accepting SSH connections.
2.1. Installation
To install sshfs on Debian-based Linux systems such as Ubuntu, we can use apt-get:
$ sudo apt-get install -y sshfs
Similarly, we can use yum to install sshfs on RHEL-based Linux systems such as CentOS:
$ sudo yum --enablerepo=powertools install fuse-sshfs
To obtain the sshfs binary on RHEL-based Linux, we may need to also install the package fuse-sshfs. To that end, we usually enable the powertools repo using the flag –enablerepo.
2.2. General Syntax
Generally, the sshfs command has a fairly common syntax:
sshfs [user@]host:[dir] mountpoint [options]
The first argument of sshfs is the connection string as per the SSH specification:
[user@]host:[dir]
The user argument specifies the username to log in as on the remote server. Then, the host argument takes the value of the IP address or domain of the remote server. Next, the optional dir argument specifies the path of the remote directory. When the value is absent, sshfs mounts within the authenticating user’s home path.
The mountpoint argument is the local path on which the mount is created. Additionally, the path specified by the mountpoint argument must exist before mounting. Of course, the command also accepts a list of optional flags that provide a variety of configurations.
2.3. Basic Usage
To mount a remote directory with sshfs, we first create a directory in the local node that serves as the mount point:
$ mkdir -p /mnt/DATA
Then, let’s mount the remote directory using sshfs:
$ sshfs [email protected]:/tmp/DATA /mnt/DATA
[email protected]'s password:
Essentially, the command above points the mount point /mnt/DATA to the remote directory /tmp/DATA on host 192.168.1.16. Additionally, we’ve chosen to connect to the host as user bob. As per the SSH specification, the remote prompts for the password for user bob.
2.4. Unmounting a Remote Directory
To unmount the directory, we can use fusermount:
$ fusermount -u /mnt/DATA
Alternatively, we can use umount to unmount the mount point:
$ umount /mnt/DATA
Depending on our scenario, both options might work.
3. sshfs Options
SSHFS mounts can have many options. Part of them stem from the SSH protocol, while another part comes from the usual mount procedure specifics.
3.1. Specifying a Different Port
If the remote server accepts SSH connections on a different port, we can specify the port using -p.
For example, we can indicate the port for the SSH connection as 2200:
$ sshfs [email protected]:/tmp/DATA /mnt/DATA -p 2200
This way, we can accommodate customized setups.
3.2. Automatic Reconnect
In the event that communication is interrupted, we can configure sshfs to automatically re-establish the connection.
To do that, we can specify the option -o reconnect:
$ sshfs [email protected]:/tmp/DATA /mnt/DATA -o reconnect
Thus, we ensure a more robust setup.
3.3. Delaying Connection
Whenever we create a mount point using sshfs, a connection is established immediately.
To delay the connection, we can apply the -o delay_connect option:
$ sshfs [email protected]:/tmp/DATA /mnt/DATA -o delay_connect
The command returns immediately without any password prompt. That’s because the flag -o delay_connect prevents connections from being made immediately. Instead, the connection is made when we first access the mount /mnt/DATA.
4. File Ownership and Permissions
sshfs provides several ways to map the user ID (UID) and group ID (GID) of the remote files and directories to equivalent local values. The mapping can be done as easily as mapping every UID and GID to a single value locally. Besides that, the mapping can be much more dynamic using a file that specifies the mapping.
4.1. Setting Owner to a Single User and Group
We can set the owner of the remote directories and files to a single user and group ID by passing the flag -o uid.
For example, the flag -o uid=1002 sets the owner of the files and directories in the mount point to the user with an ID of 1002:
$ sshfs [email protected]:/tmp/DATA /mnt/DATA -o uid=1002
[email protected]'s password:
$ ls -l /mnt/DATA
total 4
-rw-r--r-- 1 1002 alicegroup 11 Apr 10 14:28 bob-file.txt
-rw-rw-r-- 1 1002 alicegroup 12 Apr 10 14:28 joey-file.txt
Additionally, we can also set the group ID to a single local value using the flag -o gid.
For example, we can set the group ID of the file within the directory to 5005:
$ sshfs [email protected]:/tmp/DATA /mnt/DATA -o gid=5005
[email protected]'s password:
$ ls -l /mnt/DATA
total 8
-rw-r--r-- 1 alice 5005 11 Apr 10 14:28 bob-file.txt
-rw-rw-r-- 1 alice 5005 12 Apr 10 14:28 joey-file.txt
Finally, we can specify both of the flags to set the UID and GID of the files:
$ sshfs bob@ubuntu-box-p:/tmp/DATA /mnt/DATA -o uid=1002 -o gid=5005
[email protected]'s password:
$ ls -l /mnt/DATA
total 8
-rw-r--r-- 1 1002 5005 11 Apr 10 14:28 bob-file.txt
-rw-rw-r-- 1 1002 5005 12 Apr 10 14:28 joey-file.txt
In summary, these options provide more flexible control over the security of the mount.
4.2. Mapping UID and GID Dynamically
To map the remote UID and GID values locally according to a mapping file, we can pass the -o idmap=file option. Then, we specify the mapping files using the flags -o uidfile and -o gidfile.
For example, the directory /tmp/DATA on host 192.168.1.16 contains the two files, bob-file.txt, and joey-file.txt:
$ ls -l /tmp/DATA
total 8
-rw-rw-r-- 1 bob bobgroup 11 Apr 10 14:28 bob-file.txt
-rw-rw-r-- 1 joey joeygroup 12 Apr 10 14:28 joey-file.txt
First, we determine the UID and GID of bob and joey on host 192.168.1.16. To determine the UID of a user, we can use the id command and pass the -u flag:
$ id -u bob
1001
$ id -u joey
1002
Using the same command, we can obtain the GID of the user by specifying the -g flag:
$ id -g bobgroup
201
$ id -g joeygroup
202
Then, we can create a mapping rule locally to assign the remote UID and GID to the local value. The rules are indicated in a specific format:
local-username:remote-uid
In our example, we’ll map remote user bob to local user alice and remote user joey to local user amy:
$ cat > uid-mapping <<EOF
alice:1001
amy:1002
root:0
EOF
The command above writes the mapping rules into the file uid-mapping using the cat command and a heredoc.
Similarly, we can create a group ID mapping file gid-mapping to map the remote groups into local values:
$ cat > gid-mapping <<EOF
alicegroup:201
amygroup:202
root:0
EOF
Then, we can create our mount point using the command sshfs, passing the uid-mapping and gid-mapping as the rules for mapping:
$ sshfs [email protected]:/tmp/DATA /mnt/DATA -o idmap=file -o uidfile=uid-mapping -o gidfile=gid-mapping
With the -o idmap=file option, we’re telling the command sshfs to perform the mapping using files. Then, we pass the mapping filenames using the flags -o uidfile and -o gidfile.
Let’s look at the permissions information on the local mount point:
$ ls -l /mnt/DATA
total 8
-rw-rw-r-- 1 alice alicegroup 11 Apr 10 14:28 bob-file.txt
-rw-rw-r-- 1 amy amygroup 12 Apr 10 14:28 joey-file.txt
As we can see, the permissions have been mapped according to the uid-mapping and gid-mapping files.
5. Automated Mounting
Automated mounting with sshfs in Linux can boost the system’s performance by eliminating the need for manual intervention when accessing remote files. Additionally, we can perform sshfs mounts by configuring SSH keys, enabling us to access remote files securely and more conveniently.
5.1. Authentication Process
To begin with, let’s generate a new key pair on the local machine using the ssh-keygen command:
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/gautam/.ssh/id_rsa): key_file
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in key_file
Your public key has been saved in key_file.pub
The key fingerprint is:
SHA256:WXjoys8IdVniELIy6x4m08FBI4zZK0KIOzMMZl9wZdI sam@sam-HP-Laptop-15q-ds1xxx
After executing the command, we generate a pair of keys: one public key and one private key. We can find the newly generated keys in the ~/.ssh directory.
Furthermore, the next step is establishing a connection with the remote server. We can utilize the ssh-copy-id command for this task. Let’s take a look at the general syntax:
$ ssh-copy-id <username>@<remote_host>
For example, if the name of the user is bob and the IP address of the server is 192.168.1.16, the command for connection establishment with the server would include those two entities within the syntax we used earlier:
$ ssh-copy-id [email protected]
Finally, we can test the SSH connection using the username and IP address of the server:
$ ssh <username>@<remote_host>
Thus, we can proceed further after successfully establishing the SSH connection with the server.
5.2. Global and User-Specific Automation
To mount sshfs on a given machine, we add an instruction in the /etc/fstab configuration file. The /etc/fstab configuration file contains data regarding the filesystems and their mount points in Linux.
First, we open the configuration file using an editor like nano:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/nvme0n1p4 during installation
UUID=add4453a-c614-402a-9bbc-c6f860346c41 / ext2 errors=remoun>
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=9029-B985 /boot/efi vfat umask=0077 0 1
Furthermore, we add a command for sshfs mounting to the configuration file. Indeed, sshfs mounts adhere to the basic /etc/fstab syntax, but include a special prefix:
sshfs#[user]@host:[dir] mountpoint [options]
First, we can see an example:
sshfs#[email protected]:/tmp/DATA /mnt/DATA fuse defaults,_netdev,allow_other
Now, let’s break down the command:
- the type of the filesystem is sshfs
- the name of the user is bob
- the IP address of the server is 192.168.1.16
- /tmp/DATA is the remote directory to mount
- /mnt/DATA represents the local mount point
- fuse denotes the type of the filesystem in the userspace
- default denotes the default mount option
- _netdev is utilized to tell the system to wait for the network before start mounting
- the allow_user option permits all users of a system to access the mounted filesystem
Furthermore, it’s also possible to mount for a specific user. In such a case, we need to add the user name of that user and change the allow_user option to the user option.
6. Conclusion
In this article, we looked at ways to mount a remote directory using sshfs.
We started off with an installation guide for Debian-based and RHEL-based Linux systems. Then, we saw how to mount and unmount a remote directory via SSHFS. Next, we studied some of the options that sshfs provides. Moreover, we explored the permission mapping functionality of the command.
Finally, we discussed how to perform automated mounting with sshfs in Linux.