SSHFS: Difference between revisions
m (fix link) |
m (Conforming to Warning template in 4. Automounting) |
||
(88 intermediate revisions by 30 users not shown) | |||
Line 2: | Line 2: | ||
[[Category:Secure Shell]] | [[Category:Secure Shell]] | ||
[[Category:Network sharing]] | [[Category:Network sharing]] | ||
[[de:sshfs]] | |||
[[es:SSHFS]] | |||
[[fr:SSHFS]] | |||
[[ja:Sshfs]] | [[ja:Sshfs]] | ||
[[ru:SSHFS]] | [[ru:SSHFS]] | ||
Line 12: | Line 15: | ||
{{Related articles end}} | {{Related articles end}} | ||
[https://github.com/libfuse/sshfs SSHFS] is a FUSE-based filesystem client for mounting remote directories over a [[Secure Shell]] connection. | [https://github.com/libfuse/sshfs SSHFS] is a [[FUSE]]-based filesystem client for mounting remote directories over a [[Secure Shell]] connection. | ||
== Installation == | == Installation == | ||
Line 20: | Line 23: | ||
{{Tip| | {{Tip| | ||
*If you often need to mount sshfs filesystems you may be interested in using an sshfs helper, such as {{AUR|qsshfs}}, [[sftpman]], {{AUR|sshmnt}} or [https://github.com/lahwaacz/Scripts/blob/master/fmount.py fmount.py]. | *If you often need to mount sshfs filesystems you may be interested in using an sshfs helper, such as {{AUR|qsshfs}}, [[sftpman]], {{AUR|sshmnt}} or [https://github.com/lahwaacz/Scripts/blob/master/fmount.py fmount.py]. | ||
*You may want to use [[Google Authenticator]] providing additional security as in two-step authentication. | *You may want to use [[Google Authenticator]] or [[SSH keys#FIDO/U2F|Fido Tokens]] providing additional security as in two-step authentication. | ||
*[[SSH keys]] may be used over traditional password authentication.}} | *[[SSH keys]] may be used over traditional password authentication.}} | ||
Line 53: | Line 56: | ||
''sshfs'' can automatically convert between local and remote user IDs. Use the {{ic|1=idmap=user}} option to translate the UID of the connecting user to the remote user {{ic|myuser}} (GID remains unchanged): | ''sshfs'' can automatically convert between local and remote user IDs. Use the {{ic|1=idmap=user}} option to translate the UID of the connecting user to the remote user {{ic|myuser}} (GID remains unchanged): | ||
$ sshfs myuser@mycomputer:/remote/path /local/path -o idmap=user | $ sshfs ''myuser''@''mycomputer'':''/remote/path /local/path'' -o idmap=user | ||
If you need more control over UID and GID translation, look at the options {{ic|1=idmap=file}}, {{ic|uidfile}} and {{ic|gidfile}}. | If you need more control over UID and GID translation, look at the options {{ic|1=idmap=file}}, {{ic|uidfile}} and {{ic|gidfile}}. | ||
Line 79: | Line 82: | ||
== Automounting == | == Automounting == | ||
Automounting can happen on boot, or on demand (when accessing the directory). For both, the setup happens in the [[fstab]]. | |||
{{Warning|The private SSH key cannot be passphrase-protected for automounting to work (there is no interface to prompt the user for a passphrase when the mounting is triggered). Keeping the private key unencrypted on disk has security implications.}} | |||
{{Note|Keep in mind that automounting is done through the root user, therefore you cannot use hosts configured in {{ic|.ssh/config}} of your normal user. | {{Note|Keep in mind that automounting is done through the root user, therefore you cannot use hosts configured in {{ic|.ssh/config}} of your normal user. | ||
Line 88: | Line 90: | ||
To let the root user use an SSH key of a normal user, specify its full path in the {{ic|IdentityFile}} option. | To let the root user use an SSH key of a normal user, specify its full path in the {{ic|IdentityFile}} option. | ||
'''And most importantly''', use each sshfs mount at least once manually '''while root''' so the host's signature is added to the {{ic|/root/.ssh/known_hosts}} file. | '''And most importantly''', use each sshfs mount at least once manually '''while root''' on the client machine so the host's signature is added to the client's {{ic|/root/.ssh/known_hosts}} file. This can also be done manually by appending one or more of the SSH server's public host keys (the {{ic|/etc/ssh/ssh_host_*key.pub}} files) to {{ic|/root/.ssh/known_hosts}}. | ||
}} | |||
=== With systemd === | |||
{{Accuracy|What is the advantage of this compared to {{ic|/etc/fstab}}? An obvious disadvantage is that it takes too many lines to configure a single mountpoint. It is not a good idea to always do things just because they are possible.}} | |||
You will need to [[Systemd#Writing unit files|write two systemd units]]: a mount unit and an optional automount unit. [[Enabling]] the automount unit and keeping the mount unit itself disabled will not block startup and only mount once trying to access the file system. These files need to be named exactly like the mountpoint with "-" signs separating the folders within the path. | |||
Mount unit, needs to be named exactly like the mountpoint (here, {{ic|/mnt/data}} becomes {{ic|mnt-data}}): | |||
{{hc|/etc/systemd/system/mnt-data.mount|2= | |||
[Unit] | |||
Description=SSHFS (remote.local) | |||
Before=remote-fs.target | |||
[Mount] | |||
What=user@remote.local:/mnt/data | |||
Where=/mnt/data | |||
Type=fuse.sshfs | |||
Options=_netdev,rw,nosuid,allow_other,uid=1000,gid=1000,default_permissions,follow_symlinks,idmap=user,identityfile=/home/''user''/.ssh/id_ed25519 | |||
[Install] | |||
WantedBy=remote-fs.target | |||
WantedBy=multi-user.target | |||
}} | |||
The automount unit file also needs to be named exactly like the mountpoint: | |||
{{hc|/etc/systemd/system/mnt-data.automount|2= | |||
[Unit] | |||
Description=Automount /mnt/data | |||
[Automount] | |||
Where=/mnt/data | |||
TimeoutIdleSec=0 | |||
[Install] | |||
WantedBy=multi-user.target | |||
}} | }} | ||
=== On demand === | === On demand === | ||
With systemd, on-demand mounting is possible using {{ic|/etc/fstab}} entries. | |||
With systemd on-demand mounting is possible using {{ic|/etc/fstab}} entries. | |||
Example: | Example: | ||
user@host:/remote/ | ''user''@''host'':''/remote/path /local/path'' fuse.sshfs x-systemd.automount,_netdev,users,idmap=user,IdentityFile=/home/''user''/.ssh/id_rsa,allow_other,reconnect 0 0 | ||
The important mount options here are '' | The important mount options here are ''x-systemd.automount,_netdev''. | ||
* ''x-systemd.automount'' does the on-demand magic | * ''x-systemd.automount'' does the on-demand magic | ||
* ''_netdev'' tells it that it is a network device, not a block device (without it "No such device" errors might happen) | * ''_netdev'' tells it that it is a network device, not a block device (without it, "No such device" errors might happen) | ||
See also [[fstab#Automount with systemd]]. | |||
{{ | {{Note|After editing {{ic|/etc/fstab}}, [[reload]] the systemd configuration and the required services, which can be found by running {{ic|systemctl list-unit-files --type automount}}.}} | ||
=== On boot === | === On boot === | ||
Line 115: | Line 152: | ||
An example on how to use sshfs to mount a remote filesystem through {{ic|/etc/fstab}} | An example on how to use sshfs to mount a remote filesystem through {{ic|/etc/fstab}} | ||
''user''@''host'':''/remote/path /local/path'' fuse.sshfs _netdev 0 0 | |||
Take for example the ''fstab'' line | Take for example the ''fstab'' line | ||
llib@192.168.1.200:/home/llib/FAH /media/FAH2 fuse.sshfs | llib@192.168.1.200:/home/llib/FAH /media/FAH2 fuse.sshfs _netdev 0 0 | ||
The above will work automatically if you are using an SSH key for the user. See [[Using SSH Keys]]. | The above will work automatically if you are using an SSH key for the user that is not password-protected. See [[Using SSH Keys]]. | ||
If you want to use sshfs with multiple users: | If you want to use sshfs with multiple users, add the following option: | ||
user@domain.org:/home/user /media/user fuse.sshfs | user@domain.org:/home/user /media/user fuse.sshfs '''allow_other''',_netdev 0 0 | ||
In order to ensure the network is available before trying to mount, it is not only important to set the {{ic|_netdev}} mount option, but also to add either {{ic|--any}} or a specific {{ic|--interface}} to the appropriate [[systemd#Running services after the network is up|wait-online service]] for your network manager. | |||
=== Secure user access === | === Secure user access === | ||
Line 135: | Line 172: | ||
An example mountpoint configuration: | An example mountpoint configuration: | ||
''user''@''host'':''/remote/path /local/path'' fuse.sshfs noauto,x-systemd.automount,_netdev,user,idmap=user,follow_symlinks,identityfile=/home/''user''/.ssh/id_rsa,allow_other,default_permissions,uid=USER_ID_N,gid=USER_GID_N 0 0 | |||
Summary of the relevant options: | Summary of the relevant options: | ||
Line 149: | Line 186: | ||
Read [[OpenSSH#Checklist]] first. Further issues to check are: | Read [[OpenSSH#Checklist]] first. Further issues to check are: | ||
# Is your SSH login sending additional information from server's {{ic|/etc/issue}} file e.g.? This might confuse SSHFS. You should temporarily deactivate server's {{ic|/etc/issue}} file: {{bc|$ mv /etc/issue /etc/issue.orig}} | |||
# Keep in mind that most SSH related troubleshooting articles you will find on the web are '''not''' systemd related. Often {{ic|/etc/fstab}} definitions wrongly begin with {{bc|''sshfs#''user@host:/mnt/server/directory ... fuse ...}} instead of using the syntax {{bc|user@host:/mnt/server/directory ... fuse.''sshfs'' ... ''x-systemd'', ...}} | |||
# Check that the owner of server's source directory and content is owned by the server's user. {{bc|$ chown -R ''user_s'': /mnt/servers/directory}} | |||
# The server's user ID can be different from the client's one. Obviously both user names have to be the same. You just have to care for the client's user IDs. SSHFS will translate the UID for you with the following mount options:{{bc|1=uid=''USER_C_ID'',gid=''GROUP_C_ID''}} | |||
# Check that the client's target mount point (directory) is owned by the client user. This directory should have the same user ID as defined in SSHFS's mount options.{{bc|$ chown -R ''user_c'': /mnt/client/directory}} | |||
# Check that the client's mount point (directory) is empty. By default you cannot mount SSHFS directories to non-empty directories. | |||
=== Connection reset by peer === | === Connection reset by peer === | ||
* If you are trying to access the remote system with a hostname, try using its IP address, as it can be a domain name | * If you are trying to access the remote system with a hostname, try using its IP address, as it can be a domain name resolving issue. Make sure you edit {{ic|/etc/hosts}} with the server details. | ||
* If you are using non-default key | * Make sure your user can log into the server (especially when using {{ic|AllowUsers}}). | ||
* If your {{ic|/root/.ssh/config}} is a symlink, you will be getting this error as well. See [ | * Make sure {{ic|Subsystem sftp /usr/lib/ssh/sftp-server}} is enabled in {{ic|/etc/ssh/sshd_config}} on the remote system. | ||
* Adding the option | * If you are using a non-default key name and passing it as {{ic|-i .ssh/my_key}}, this will not work. You have to use {{ic|1=-o IdentityFile=/home/''user''/.ssh/''my_key''}}, with the full path to the key. | ||
* If that | * If your {{ic|/root/.ssh/config/}} is a symlink, you will be getting this error as well. See [https://serverfault.com/questions/507748/bad-owner-or-permissions-on-root-ssh-config this serverfault topic] | ||
* If you are trying to sshfs into a router running DD-WRT or the like, there is a solution [ | * Adding the option {{ic|sshfs_debug}} (as in {{ic|sshfs -o sshfs_debug ''user''@''server'' ...}}) can help in resolving the issue. | ||
* If you see this only on boot, it may be that systemd is attempting to mount prior to a network connection being available. Enabling the | * If that does not reveal anything useful, you might also try adding the option {{ic|debug}}. | ||
* Old Forum thread: [https://bbs.archlinux.org/viewtopic.php?id=27613 sshfs: Connection reset by peer] | * If you are trying to sshfs into a router running DD-WRT or the like, there is a solution [https://www.dd-wrt.com/wiki/index.php/SFTP_with_DD-WRT here]. (Note that the {{ic|1=-osftp_server=/opt/libexec/sftp-server}} option can be used to the sshfs command instead of patching dropbear). | ||
* If you see this only on boot, it may be that systemd is attempting to mount prior to a network connection being available. Enabling the appropriate [[systemd#Running services after the network is up|wait-online service]] for your network manager fixes this. | |||
* Old Forum thread: [https://bbs.archlinux.org/viewtopic.php?id=27613 sshfs: Connection reset by peer]. | |||
{{Note| When providing more than one option for sshfs, they must be comma separated. Like so: | {{Note|When providing more than one option for sshfs, they must be comma separated. Like so: {{ic|1=sshfs -o sshfs_debug,IdentityFile=''/path/to/key'' ''user''@''server'' ...}}).}} | ||
=== Remote host has disconnected === | === Remote host has disconnected === | ||
Line 200: | Line 224: | ||
To be able to run {{ic|mount -av}} and see the debug output, remove the following: | To be able to run {{ic|mount -av}} and see the debug output, remove the following: | ||
noauto,x-systemd.automount | noauto,x-systemd.automount | ||
=== Some directories are empty === | |||
sshfs by default does not support symlinks. If those directories happened to be symlinks, use: | |||
$ sshfs ''user''@''host'':''/remote/path /local/path'' -o follow_symlinks | |||
=== Files not refreshed === | |||
If you see old content on remote, consider using option {{ic|1=dir_cache=no}}: | |||
$ sshfs ''user''@''host'':''/remote/path /local/path'' -o dir_cache=no | |||
=== Limited transfer on fast network === | |||
If you observe transfer than is lower than your network capabilities and high CPU usage on the party where files are copied from, disable compression (remove {{ic|-C}} option or set {{ic|1=-o compression=no}}). | |||
== See also == | == See also == | ||
* [ | * [https://wiki.gilug.org/index.php/How_to_mount_SFTP_accesses How to mount chrooted SSH filesystem], with special care with owners and permissions questions. |
Latest revision as of 04:30, 21 February 2024
SSHFS is a FUSE-based filesystem client for mounting remote directories over a Secure Shell connection.
Installation
- If you often need to mount sshfs filesystems you may be interested in using an sshfs helper, such as qsshfsAUR, sftpman, sshmntAUR or fmount.py.
- You may want to use Google Authenticator or Fido Tokens providing additional security as in two-step authentication.
- SSH keys may be used over traditional password authentication.
Mounting
In order to be able to mount a directory the SSH user needs to be able to access it. Invoke sshfs to mount a remote directory:
$ sshfs [user@]host:[dir] mountpoint [options]
For example:
$ sshfs myuser@mycomputer:/remote/path /local/path -C -p 9876
Here -p 9876
specifies the port number and -C
enables compression. For more options see the #Options section.
When not specified, the remote path defaults to the remote user home directory. Default user names and options can be predefined on a host-by-host basis in ~/.ssh/config
to simplify the sshfs usage. For more information see OpenSSH#Client usage.
SSH will ask for the password, if needed. If you do not want to type in the password multiple times a day, see SSH keys.
Unmounting
To unmount the remote system:
$ fusermount3 -u mountpoint
Example:
$ fusermount3 -u /local/path
Options
sshfs can automatically convert between local and remote user IDs. Use the idmap=user
option to translate the UID of the connecting user to the remote user myuser
(GID remains unchanged):
$ sshfs myuser@mycomputer:/remote/path /local/path -o idmap=user
If you need more control over UID and GID translation, look at the options idmap=file
, uidfile
and gidfile
.
A complete list of options can be found in sshfs(1).
Chrooting
You may want to restrict a specific user to a specific directory on the remote system. This can be done by editing /etc/ssh/sshd_config
:
/etc/ssh/sshd_config
..... Match User someuser ChrootDirectory /chroot/%u ForceCommand internal-sftp AllowTcpForwarding no X11Forwarding no .....
See also SFTP chroot. For more information check the sshd_config(5) man page for Match
, ChrootDirectory
and ForceCommand
.
Automounting
Automounting can happen on boot, or on demand (when accessing the directory). For both, the setup happens in the fstab.
.ssh/config
of your normal user.
To let the root user use an SSH key of a normal user, specify its full path in the IdentityFile
option.
And most importantly, use each sshfs mount at least once manually while root on the client machine so the host's signature is added to the client's /root/.ssh/known_hosts
file. This can also be done manually by appending one or more of the SSH server's public host keys (the /etc/ssh/ssh_host_*key.pub
files) to /root/.ssh/known_hosts
.
With systemd
You will need to write two systemd units: a mount unit and an optional automount unit. Enabling the automount unit and keeping the mount unit itself disabled will not block startup and only mount once trying to access the file system. These files need to be named exactly like the mountpoint with "-" signs separating the folders within the path.
Mount unit, needs to be named exactly like the mountpoint (here, /mnt/data
becomes mnt-data
):
/etc/systemd/system/mnt-data.mount
[Unit] Description=SSHFS (remote.local) Before=remote-fs.target [Mount] What=user@remote.local:/mnt/data Where=/mnt/data Type=fuse.sshfs Options=_netdev,rw,nosuid,allow_other,uid=1000,gid=1000,default_permissions,follow_symlinks,idmap=user,identityfile=/home/user/.ssh/id_ed25519 [Install] WantedBy=remote-fs.target WantedBy=multi-user.target
The automount unit file also needs to be named exactly like the mountpoint:
/etc/systemd/system/mnt-data.automount
[Unit] Description=Automount /mnt/data [Automount] Where=/mnt/data TimeoutIdleSec=0 [Install] WantedBy=multi-user.target
On demand
With systemd, on-demand mounting is possible using /etc/fstab
entries.
Example:
user@host:/remote/path /local/path fuse.sshfs x-systemd.automount,_netdev,users,idmap=user,IdentityFile=/home/user/.ssh/id_rsa,allow_other,reconnect 0 0
The important mount options here are x-systemd.automount,_netdev.
- x-systemd.automount does the on-demand magic
- _netdev tells it that it is a network device, not a block device (without it, "No such device" errors might happen)
See also fstab#Automount with systemd.
/etc/fstab
, reload the systemd configuration and the required services, which can be found by running systemctl list-unit-files --type automount
.On boot
An example on how to use sshfs to mount a remote filesystem through /etc/fstab
user@host:/remote/path /local/path fuse.sshfs _netdev 0 0
Take for example the fstab line
llib@192.168.1.200:/home/llib/FAH /media/FAH2 fuse.sshfs _netdev 0 0
The above will work automatically if you are using an SSH key for the user that is not password-protected. See Using SSH Keys.
If you want to use sshfs with multiple users, add the following option:
user@domain.org:/home/user /media/user fuse.sshfs allow_other,_netdev 0 0
In order to ensure the network is available before trying to mount, it is not only important to set the _netdev
mount option, but also to add either --any
or a specific --interface
to the appropriate wait-online service for your network manager.
Secure user access
When automounting via fstab, the filesystem will generally be mounted by root. By default, this produces undesireable results if you wish access as an ordinary user and limit access to other users.
An example mountpoint configuration:
user@host:/remote/path /local/path fuse.sshfs noauto,x-systemd.automount,_netdev,user,idmap=user,follow_symlinks,identityfile=/home/user/.ssh/id_rsa,allow_other,default_permissions,uid=USER_ID_N,gid=USER_GID_N 0 0
Summary of the relevant options:
- allow_other - Allow other users than the mounter (i.e. root) to access the share.
- default_permissions - Allow kernel to check permissions, i.e. use the actual permissions on the remote filesystem. This allows prohibiting access to everybody otherwise granted by allow_other.
- uid, gid - set reported ownership of files to given values; uid is the numeric user ID of your user, gid is the numeric group ID of your user.
Troubleshooting
Checklist
Read OpenSSH#Checklist first. Further issues to check are:
- Is your SSH login sending additional information from server's
/etc/issue
file e.g.? This might confuse SSHFS. You should temporarily deactivate server's/etc/issue
file:$ mv /etc/issue /etc/issue.orig
- Keep in mind that most SSH related troubleshooting articles you will find on the web are not systemd related. Often
/etc/fstab
definitions wrongly begin withsshfs#user@host:/mnt/server/directory ... fuse ...
instead of using the syntaxuser@host:/mnt/server/directory ... fuse.sshfs ... x-systemd, ...
- Check that the owner of server's source directory and content is owned by the server's user.
$ chown -R user_s: /mnt/servers/directory
- The server's user ID can be different from the client's one. Obviously both user names have to be the same. You just have to care for the client's user IDs. SSHFS will translate the UID for you with the following mount options:
uid=USER_C_ID,gid=GROUP_C_ID
- Check that the client's target mount point (directory) is owned by the client user. This directory should have the same user ID as defined in SSHFS's mount options.
$ chown -R user_c: /mnt/client/directory
- Check that the client's mount point (directory) is empty. By default you cannot mount SSHFS directories to non-empty directories.
Connection reset by peer
- If you are trying to access the remote system with a hostname, try using its IP address, as it can be a domain name resolving issue. Make sure you edit
/etc/hosts
with the server details. - Make sure your user can log into the server (especially when using
AllowUsers
). - Make sure
Subsystem sftp /usr/lib/ssh/sftp-server
is enabled in/etc/ssh/sshd_config
on the remote system. - If you are using a non-default key name and passing it as
-i .ssh/my_key
, this will not work. You have to use-o IdentityFile=/home/user/.ssh/my_key
, with the full path to the key. - If your
/root/.ssh/config/
is a symlink, you will be getting this error as well. See this serverfault topic - Adding the option
sshfs_debug
(as insshfs -o sshfs_debug user@server ...
) can help in resolving the issue. - If that does not reveal anything useful, you might also try adding the option
debug
. - If you are trying to sshfs into a router running DD-WRT or the like, there is a solution here. (Note that the
-osftp_server=/opt/libexec/sftp-server
option can be used to the sshfs command instead of patching dropbear). - If you see this only on boot, it may be that systemd is attempting to mount prior to a network connection being available. Enabling the appropriate wait-online service for your network manager fixes this.
- Old Forum thread: sshfs: Connection reset by peer.
sshfs -o sshfs_debug,IdentityFile=/path/to/key user@server ...
).Remote host has disconnected
If you receive this message directly after attempting to use sshfs:
- First make sure that the remote machine has sftp installed! It will not work, if not.
- Then, check that the path of the
Subsystem sftp
in/etc/ssh/sshd_config
on the remote machine is valid.
fstab mounting issues
To get verbose debugging output, add the following to the mount options:
ssh_command=ssh\040-vv,sshfs_debug,debug
\040
represents a space which fstab uses to separate fields.To be able to run mount -av
and see the debug output, remove the following:
noauto,x-systemd.automount
Some directories are empty
sshfs by default does not support symlinks. If those directories happened to be symlinks, use:
$ sshfs user@host:/remote/path /local/path -o follow_symlinks
Files not refreshed
If you see old content on remote, consider using option dir_cache=no
:
$ sshfs user@host:/remote/path /local/path -o dir_cache=no
Limited transfer on fast network
If you observe transfer than is lower than your network capabilities and high CPU usage on the party where files are copied from, disable compression (remove -C
option or set -o compression=no
).
See also
- How to mount chrooted SSH filesystem, with special care with owners and permissions questions.