Sshfs

De ArchwikiFR

Traduit du : WIKI

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

-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 defaut. 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 ~/.ssh/config pour éviter l'usage de l'option '-p' ici. Informations complémentaires sur SSH - Client.


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 aur/sftpman, aur/sftpman-gtk.

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 (when accessing the directory). 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

Attention : Article demandant à être développé : Existe - t-il un moyen de faire fonctionner cette clé privée avec une clé privée protégée par mot de passe? Par exemple, il demande la phrase de passe au premier accès. Sinon, indiquez clairement que ce n'est pas possible et pourquoi.

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 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><target> sera fourni par le retour de : systemctl list-unit-files --type automount
Astuce : autosshfs-git 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 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 SSH-Checklist du Wiki. 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 Connection 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 entrainera 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 rappor de bug pour détails et/ou solutions.


Blocage de l'extinction en cas de montage sshfs

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