SSHFS

出自 Arch Linux 中文维基

本文或本節需要翻譯。要貢獻翻譯,請訪問簡體中文翻譯團隊

附註: 部分內容未翻譯(在 Talk:SSHFS# 中討論)

SSHFS 是一個通過 SSH 掛載基於 FUSE 的文件系統的客戶端程序。

注意: 開發者已經停止開發此項目,rclone 提供了相同的掛載功能。

安裝[編輯 | 編輯原始碼]

安裝 軟件包 sshfs

提示:
  • 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 providing additional security as in two-step authentication.
  • SSH keys may be used over traditional password authentication.

掛載[編輯 | 編輯原始碼]

只能掛載 SSH 用戶可以訪問的目錄,用 sshfs 掛載遠程目錄:

$ sshfs [user@]host:[dir] mountpoint [options]

示例:

$ sshfs myuser@mycomputer:/remote/path /local/path -C -p 9876

-p 9876 指定端口號,-C 啟用壓縮。

未指定是默認掛載遠程用戶的主目錄,默認的用戶名和密碼可以通過 ~/.ssh/config 按主機進行配置,這樣可以簡化 sshfs 命令。詳情請參考 OpenSSH#Client usage

需要密碼時,SSH 會提示輸入,如果不想一直手動輸入,可以使用 SSH keys

卸載[編輯 | 編輯原始碼]

要卸載遠程系統:

$ fusermount3 -u mountpoint

例如:

$ fusermount3 -u /local/path

選項[編輯 | 編輯原始碼]

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
.....
注意: 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.

Automounting[編輯 | 編輯原始碼]

Automounting can happen on boot, or on demand (when accessing the directory). For both, the setup happens in the fstab.

注意: 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 the SSH server's public host keys (the /etc/ssh/ssh_host_*key.pub files) to /root/.ssh/known_hosts.

On demand[編輯 | 編輯原始碼]

這篇文章的某些內容需要擴充。

原因: Is there a way to make this work with a passphrase-protected private key? E.g. it prompts for the passphrase at first access. Alternatively, clearly state that it is not possible and why. (在 Talk:SSHFS 中討論)

With systemd on-demand mounting is possible using /etc/fstab entries.

Example:

user@host:/remote/path /local/path  fuse.sshfs noauto,x-systemd.automount,_netdev,users,idmap=user,IdentityFile=/home/user/.ssh/id_rsa,allow_other,reconnect 0 0

The important mount options here are noauto,x-systemd.automount,_netdev.

  • noauto tells it not to mount at boot
  • 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)
注意: 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 filesystem through /etc/fstab

user@host:/remote/path  /local/path  fuse.sshfs  defaults,_netdev  0  0

Take for example the fstab line

llib@192.168.1.200:/home/llib/FAH  /media/FAH2  fuse.sshfs  defaults,_netdev  0  0

The above will work automatically if you are using an SSH key for the user. 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    defaults,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:

  1. 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
  2. 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, ...
  3. 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
  4. 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
  5. 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
  6. 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.
注意: 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
注意: 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 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[編輯 | 編輯原始碼]