SSHFS (Français)

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

La traduction de cet article ou section ne reflète pas le texte original.

Raison: Out of sync with English page (Discuss in Talk:SSHFS (Français)#)

SSHFS est un client de système de fichiers, basé sur FUSE, pour le montage de répertoires par l'intermédiaire de SSH.

Installation

Installez le paquet sshfs. Vérifiez la présence des modules fuse :

$ ls -lsa /lib/modules/$(uname -r)/kernel/fs/fuse

et qu'ils soient chargés:

$ lsmod |grep fuse

Montage

Astuce: une authentification par Google Authenticator peut apporter une sécurité supplémentaire.

Pour pouvoir monter un répertoire, l'utilisateur SSH doit pouvoir y accéder.

Monter un répertoire distant par appel sshfs:

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

Par exemple:

$ sshfs sessy@mycomputer:/remote/path /local/path -C -p 9876 -o allow_other

où -p 9876 indique le numéro du port, -C active la compression et -o allow_other concède aux utilisateurs non-root l'accès en lecture/écriture.

Note: L'option allow_other est désactivée par défaut. Pour l'activer, décommenter la ligne user_allow_other dans /etc/fuse.conf ce qui activera l'autorisation de l'option de montage aux utilisateurs non-root.

Note: Les Utilisateur peuvent aussi définir un port de connexion hôte-hôte non-standard de base dans le fichier de configuration ~/.ssh/config pour éviter l'usage de l'option '-p' ici. Informations complémentaires sur l'utilisation du client SSH (en).

SSH demandera de renseigner le mot-de-passe, si nécessaire. Pour éviter d'avoir à répéter cette manœuvre plusieurs fois par jour, voir Clé publique/privée, How to Use RSA Key Authentication with SSH ou SSH keys.

Démontage

Démonter le système distant:

$ fusermount -u LOCAL_MOUNT_POINT

Exemple:

$ fusermount -u /mnt/sessy

Chroot

Vous pouvez astreindre un utilisateur (précis) à l'utilisation du protocole SFTP pour l'accès à un répertoire en éditant /etc/ssh/sshd_config:

/etc/ssh/sshd_config

.....
Match User someuser 
       ChrootDirectory /chroot/%u
       ForceCommand internal-sftp #to restrict the user to sftp only
       AllowTcpForwarding no
       X11Forwarding no
.....

Note: Le répertoire chroot doit appartenir à root, sinon vous ne pourrez pas vous connecter.

Voir aussi SFTP chroot. Informations complémentaires dans les man de Match, ChrootDirectory et ForceCommand.

Facilitateurs

En cas d'usage fréquent du montage sshfs vous serez peut-être intéressé par un programme-assistant tels sftpman^AUR, sftpman-gtk^AUR.

Ils apportent l'usage, en ligne de commande, ou avec une interface graphique GTK, d'un montage ou démontage d'une seule commande ou d'un simple clic.

Montage automatique

Le montage peut être automatisé au démarrage, ou sur demande (lors de l'accès au dossier), l'un comme l'autre se définissent dans /etc/fstab.

Note: Soyez conscient que le montage automatique se fait par l'utilisateur root et donc que vous ne pourrez pas vous servir des Hôtes définis dans le fichier personnel de votre home .ssh/config.

Pour permettre à l'utilisateur root d'utiliser la clé SSH d'un utilisateur normal, spécifiez son chemin complet dans l'option IdentityFile.

Et surtout, utilisez le montage sshfs au moins une fois manuellement en root pour que la signature de l'hôte s'ajoute au fichier .ssh/known_hosts.

Sur demande

Systemd permet le montage on-demand par des entrées dans /etc/fstab.

Exemple:

user@host:/répertoire/distant /mount/point  fuse.sshfs noauto,x-systemd.automount,_netdev,users,idmap=user,IdentityFile=/home/user/.ssh/id_rsa,allow_other,reconnect 0 0

Les options de montage importantes ici sont: noauto,x-systemd.automount,_netdev.

noauto pour ne pas avoir de montage automatique au démarrage
x-systemd.automount éxécutera "magiquement" le montage, "à-la-demande"
_netdev indique qu'il s'agit d'un périphérique réseau, et non d'un périphérique de type bloc (évitant ainsi l'erreur "Pas de périphérique de ce type")

Note: Après la modification du fichier /etc/fstab, (re)démarrez le service requis par la commande : systemctl daemon-reload && systemctl restart <target> où <target> sera fourni par le retour de : systemctl list-unit-files --type automount

Astuce: autosshfs-git^AUR^{[broken link: package not found]} ne nécessite pas la modification de /etc/fstab pour ajouter un nouveau point de montage. À la place, les utilisateurs habituels peuvent en créer un en y accédant simplement, (p.ex. avec une commande du genre de ls ~/mnt/ssh/[user@]yourremotehost[:port]). autosshfs-git^AUR^{[broken link: package not found]} utilise AutoFS. Il est nécessaire d'activer les utilisateurs dans autosshfs-user.

Au démarrage

Exemple d'ajout à /etc/fstab permettant d'utiliser le montage d'un système de fichiers distant par sshfs :

USERNAME@HOSTNAME_OR_IP:/REMOTE/DIRECTORY  /LOCAL/MOUNTPOINT  fuse.sshfs  defaults,_netdev  0  0

p.ex. : ligne fstab

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

Ceci fonctionnera automatiquement avec l'utilisation d'une clé-SSH par l'Utilisateur. Voir SSH keys.

Pour utiliser sshfs avec des utilisateurs multiples :

user@domain.org:/home/user  /media/user   fuse.sshfs    defaults,allow_other,_netdev    0  0

Répétons-le, l'option de montage _netdev, est importante pour s'assurer d'une connexion-réseau avant le montage.

Accès Sécurisé par Utilisateur

Dans le montage automatique via /etc/fstab, le système de fichiers est en général monté par l'utilisateur en tant queroot, par défaut, ce qui a des effets indésirables pour l'accès en tant qu'utilisateur ordinaire et limite l'accès des autres utilisateurs.

Exemple de configuration de point de montage :

USERNAME@HOSTNAME_OR_IP:/REMOTE/DIRECTORY  /LOCAL/MOUNTPOINT  fuse.sshfs noauto,x-systemd.automount,_netdev,user,idmap=user,follow_symlinks,identityfile=/home/USERNAME/.ssh/id_rsa,allow_other,default_permissions,uid=USER_ID_N,gid=USER_GID_N 0 0

Résumé des options pertinentes :

allow_other - Autorise les utilisateurs autres que le propriétaire du montage (p.ex. root) à accéder au partage.
default_permissions - Autorise le noyau à vérifier les permissions, ce qui signifie utiliser les autorisations réelles du système de fichiers distant. Cela permet d'interdire l'accès à tous autrement accordé par "allow_other".
uid, gid - définit la possession de fichiers par rapport à des valeurs données; Uid est l'ID utilisateur numérique de votre utilisateur, GID est l'ID de groupe numérique de votre utilisateur.

Options

Sshfs peut convertir automatiquement vos identifiants utilisateur locaux et distants.

Ajouter l'option idmap avec la valeur de l' utilisateur pour traduire l'UID de connexion utilisateur:

# sshfs -o idmap=user sessy@mycomputer:/home/sessy /mnt/sessy -C -p 9876

Cela permettra de mapper l'UID de l'utilisateur distant "sessy" à l'utilisateur local qui exécute ce processus ("root" dans l'exemple ci-dessus), le GID restant inchangé. Si vous avez besoin d'un contrôle plus précis de la traduction UID et GID, regardez les options idmap = file et uidfile et gidfile .

Anomalies

Checklist

Voyez d'abord le paragraphe SSHFS#Checklist. Les problèmes ultérieurs à contrôler seront :

1. Votre connexion SSH envoie-t-elle des informations supplémentaires du fichier serveur /etc/issue, par exemple? Cela pourrait rendre SSHFS confus. Vous devriez alors désactiver temporairement le fichier /etc/issue du serveur par :

$ mv /etc/issue /etc/issue.orig

2. Soyez conscients que la plupart des articles du web traitant d'anomalies des connexions SSH ne concernent pas des systèmes gérés par Systemd. Souvent les définitions /etc/fstab commenceront à tort par sshfs#user@host:/mnt/server/folder ... fuse ... au lieu de la syntaxe correcte user@host:/mnt/server/folder ... fuse.sshfs ... x-systemd, ....

3. Assurez-vous que, sur le Serveur, ce soit le même utilisateur qui ait les droits des répertoires source et de leur contenu d'une part, la session d'autre part.

$ chown -R USER_S: /mnt/servers/folder

4. L'ID de l'utilisateur du Serveur peut différer de celle du Client. Très évidemment les noms d'utilisateurs doivent être identiques des deux côtés. Vous n'avez à vous préoccuper que des ID de l'utilisateur-Client. SSHFS traduira pour vous les UID avec les options de montage suivantes :

uid=USER_C_ID,gid=GROUP_C_ID

5. Vérifiez que le dossier du point de montage Client appartienne bien à l'utilisateur-Client. ce dossier doit avoir le même ID d'utilisateur que celui défini dans les options de montage SSHFS .

$ chown -R USER_C: /mnt/client/folder

6. Vérifiez que le (dossier) point de montage du Client soit bien vide, par défaut l'option -o nonempty de SSHFS est activée .

7. Si vous souhaitez un partage SSH automatique avec authentification par clé publique (sans mot de passe) monté par le fichier /etc/fstab, voyez cette ligne d'exemple :

USER_S@SERVER:/mnt/on/server /nmt/on/client    use.sshfs     x-systemd.automount,_netdev,user,idmap=user,transform_symlinks,identityfile=/home/USER_C/.ssh/id_rsa,allow_other,default_permissions,uid=USER_C_ID,gid=GROUP_C_ID,umask=0   0 0

Détails des configurations de l'exemple :

SERVER = Server host name (serv) = Nom de l'hôte du serveur (serv) USER_S = Server user name (pete) = Nom de l'utilisateur du serveur USER_C = Client user name (pete) = Nom de l'utilisateur du client USER_S_ID = Server user ID (1004) = ID de l'utilisateur du serveur USER_C_ID = Client user ID (1000) = ID de l'utilisateur du client GROUP_C_ID = Client user's group ID (100) = ID du groupe de l'utilisateur du client

Vous obtenez l'ID de l'utilisateur et l'ID du groupe du Client par :

$ id USERNAME

Dernière ligne de montage SSHFS dans /etc/fstab :

pete@serv:/mnt/on/server      /nmt/on/client        fuse.sshfs      x-systemd.automount,_netdev,user,idmap=user,transform_symlinks,identityfile=/home/pete/.ssh/id_rsa,allow_other,default_permissions,uid=1004,gid=1000,umask=0   0 0

8. Merci d'ajouter ici votre expérience d'autres problèmes pour compléter la checklist ci-dessus.

Réinitialisation de la Connexion appairée

Si vous essayez d'accéder au système distant avec un nom d'hôte, essayez d'utiliser son adresse IP, car il peut s'agir d'un problème de résolution de nom de domaine. Assurez-vous d'éditer /etc/hosts avec les détails du serveur.
Si vous utilisez d'autres noms de clés que celles par défaut et les ayez définies comme -i .ssh/my_key, cela ne fonctionnera pas. Vous devez utiliser -o IdentityFile=/home/user/.ssh/my_key avec le chemin complet de la clé.
Si votre /root/.ssh/config est un lien symbolique, vous obtiendrez également cette erreur. Voir ce post pour "Server Fault"
Ajouter l'option 'sshfs_debug' (comme dans 'sshfs -o sshfs_debug user@server ...) peut aider à résoudre le problème.
Si cela n'apporte rien, vous pouvez également essayer d'ajouter l'option 'debug'
Si vous essayez une connexion sshfs dans un routeur exécutant DD-WRT ou similaire, il y a une solution ici. (Notez que l'option -osftp_server =/opt/libexec/sftp-server peut être utilisée pour la commande sshfs à la place d'un patch sur dropbear)
Ancien thread du forum: sshfs: Connection reset by peer
Assurez-vous que votre utilisateur peut se connecter au serveur (surtout lorsque vous utilisez AllowUsers)
Assurez-vous que Subsystem sftp /usr/lib/ssh/sftp-serversoit activé (enable) dans /etc/ssh/sshd_config.

Note: De multiples options pour sshfs doivent être séparées par des virgules. Ainsi: 'sshfs -o sshfs_debug,IdentityFile=</path/to/key> user@server ...')

Déconnexion de L'Hôte

Si vous recevez le message "Remote host has disconnected" immédiatement après un essai de connexion sshfs:

Assurez-vous d'abord que sshfs et sa dépendance openssh - qui fournit sftp - soient installés sur la machine distante, rien ne pouvant fonctionner sans cela...
Puis vérifiez que le chemin de Subsystem sftp dans /etc/ssh/sshd_config sur la machine distante soit valide.

Gel des applicationss (p.ex. Fichiers Gnome, Gedit)

Note: Ceci empêchera de remplir la liste des fichiers récemment utilisés et entraînera peut-être des erreurs d'écriture.

Si vous subissez des gels/blocages (freeze) d'applications, vous pourriez avoir à désactiver l'accès en écriture du fichier ~/recently-used.xbel :

# chattr +i /home/USERNAME/.local/share/recently-used.xbel

Voir ce rapport de bug pour détails et/ou solutions.

Blocage de l'extinction en cas de montage sshfs

Attention: En Discussion : on ne veut généralement "tuer" aucun processus sshfs pour un arrêt manuel du service. (À discuter en conversation: SSHFS # )

Systemd peut se bloquer à l'extinction si un support sshfs a été monté manuellement et non dé-monté avant l'arrêt. Pour résoudre ce problème, créez ce fichier (en root):

/etc/systemd/system/killsshfs.service

[Unit]
After=network.target

[Service]
RemainAfterExit=yes
ExecStart=-/bin/true
ExecStop=-/usr/bin/pkill -x sshfs

[Install]
WantedBy=multi-user.target

Puis activez le service: systemctl enable killsshfs.service

Problèmes de montages fstab

Pour un retour détaillé de la sortie de debuggage, ajouter ce qui suit aux options de montage :

ssh_command=ssh\040-vv,sshfs_debug,debug

Note: Ici, \040 represente l'espace qu'utilise fstab pour séparer ses champs.

Pour pouvoir lancer mount -av et voir la sortie de débuggage, enlever les options:

 noauto,x-systemd.automount

Voir aussi

How to mount chrooted SSH filesystem, avec une attention particulière aux questions de droits et propriétaires.
SSHFS – Installation and Performance — Comparaison avec NFS et conseils d'optimisation.