SSHFS (Magyar)

Related articles
SCP and SFTP
SFTP chroot
Pure-FTPd
sftpman
SSHFS
is a
FUSE
-based file system client for mounting remote directories over a
Secure Shell
connection.
Telepítés
Install
the
sshfs
package.
Tipp
If you often need to mount sshfs file systems you may be interested in using an sshfs helper, such as
sftpman
,
sshmnt
AUR
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.
Használat
Megjegyzés
It is
recommended
to run SSHFS as regular user (
not as root
). For this to work, the mountpoint must be owned by the user. See
mount.fuse(8) § SECURITY
for details.
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
A complete list of options can be found in
sshfs(1)
and
mount.fuse(8)
.
User ID mapping
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
.
allow_root or allow_other
Tip
As hinted in
mount.fuse(8) § SECURITY
you should be careful using these options.
$ sshfs
myuser
@
mycomputer
:
/remote/path /local/path
-o allow_other,default_permissions,uid=1002,gid=1002
allow_other
- Allow other users than the mounter (i.e. root) to access the share.
allow_root
- Similar to allow_other but file access is limited to the user mounting the file system and root.
allow_root and allow_other are mutually exclusive. Additionally you want to edit
/etc/fuse.conf
and uncomment the string
user_allow_other
to enable all users to use these options.
default_permissions
- might be also used because fuse by default does not check file access permissions. i.e. use the actual permissions on the remote file system. This allows prohibiting access to everybody otherwise granted by
allow_other
.
Change ownership of mountpoint
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.
Tippek és trükkök
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
.....
Note
The chroot directory
must
be owned by root, otherwise you will not be able to connect.
See also
SFTP chroot
. For more information check the
sshd_config(5)
man page for
Match
,
ChrootDirectory
and
ForceCommand
.
systemd
Similar to other file system mounts see
systemd.mount(5)
and possibly
systemd.automount(5)
. Because of the FUSE system and its mechanics you should use
user units
. Setup SSH with public key authentication.
As user unit
This article or section needs language, wiki syntax or style improvements. See
Help:Style
for reference.
Reason:
Add an example of a working user
.mount
unit. (Discuss in
Talk:SSHFS (Magyar)
)
Place the
foo
.mount
inside
${XDG_CONFIG_HOME}/systemd/user/
.
Start
the unit as usual with the
--user
option.
Note
systemd.automount(5) § DESCRIPTION
says: "Note that automount support on Linux is privileged, automount units are hence only available in the system service manager (and root's user service manager), but not in unprivileged users' service managers."
Use ssh-key with passphrase
Note
The user has to enter the passphrase for the ssh-key manually, this is not intended to work without any user interaction.
See
SSH keys#Start ssh-agent with systemd user
.
Generate .mount and .automount files
This article or section is being considered for removal.
Reason:
Using sshfs in fstab is explained in
#systemd root and multiple user
along with a big warning. (Discuss in
Talk:SSHFS (Magyar)
)
Create an entry in /etc/fstab
with at least _netdev
,
x-systemd.automount
is only necessary if you need automount functionality.
/etc/fstab
remoteuser@remotehost:/remote/folder /home/foo/local_folder fuse.sshfs
_netdev,x-systemd.automount,x-systemd.idle-timeout=5min,
rw   0   0
Tip
If you can manually mount a remote file system with the sshfs command, then you probably can copy the last line from
/proc/mounts
and insert the highlighted part.
# systemctl daemon-reload
All the generated files are after the daemon-reload command in
/run/systemd/generator/
. For user units you can copy the files you need and remove the fstab line and reload systemd
Write .mount and .automount files
This article or section needs language, wiki syntax or style improvements. See
Help:Style
for reference.
Reason:
This seems to be out of place, the
systemd root
section starts below. (Discuss in
Talk:SSHFS (Magyar)
)
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
):
systemd-escape -p --suffix=mount "/mnt/data/"
mnt-data.mount
/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
systemd root and multiple user
The factual accuracy of this article or section is disputed.
Reason:
There are only a few use cases in lets say home environments, where you want to use these tricks, but you have to bend always something (e.g. allow_other, ssh-keys ...). Using fstab to have it mount at boot time without passphrase is probably not really necessary. Consider using systemd User- units for all users who need it. (Discuss in
Talk:SSHFS (Magyar)
)
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
.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
.
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
.
Note
After editing
/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 file system 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
The factual accuracy of this article or section is disputed.
Reason:
The
Secure user access
is misleading, the
allow_other
option removes some "security" aspect (
mount.fuse(8) § SECURITY
). (Discuss in
Talk:SSHFS (Magyar)
)
When automounting via
fstab
, the file system 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
See
#allow_root or allow_other
for the explanation of the options used.
Hibaelhárítás
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 with
sshfs#
user@host:/mnt/server/directory ... fuse ...
instead of using the syntax
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.
$ 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 in
sshfs -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
.
Note
When providing more than one option for sshfs, they must be comma separated. Like so:
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
Note
Here,
\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 speed on fast network
If you observe transfer speed that 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
).
További olvasnivaló a témában
How to mount chrooted SSH file system
, with special care with owners and permissions questions.