sshfs avec fstab: réinitialisation de la connexion par l'homologue


10

J'essaie d'autoriser mon ordinateur portable (Ubuntu 13.04) à accéder au disque dur de mon PC (Lubuntu 13.04) via SSHFS. J'utilise des clés RSA pour me connecter.

Cela fonctionne parfaitement bien si je tape ceci dans le terminal:

sshfs my-PC:/a_folder /media/a_folder

Mais j'aimerais qu'il soit monté automatiquement lorsque je démarre mon ordinateur portable. Je me suis donc ajouté au groupe de fusibles:

sudo adduser mynickname fuse

Et j'ai ajouté la ligne suivante à mon fichier fstab:

sshfs#mynickname@my-PC:/a_folder /media/a_folder fuse defaults,idmap=user,_netdev 0 0

Lorsque je démarre l'ordinateur portable, un_folder apparaît dans la liste des appareils, mais n'est pas monté. Lorsque j'essaie d'y accéder via Nautilus, il affiche l'erreur suivante:

mount: only root can mount sshfs#mynickname@my-PC:/a_folder on /media/a_folder

J'obtiens la même erreur si j'essaye

mount /media/a_folder

dans un terminal.

Si j'essaye

sudo mount /media/a_folder

Je reçois

read: Connection reset by peer

J'ai essayé d'ajouter "allow_other" comme option dans l'entrée fstab, et je n'ai pas commenté la ligne associée dans /etc/fuse.conf, mais cela n'a rien changé.

L'utilisateur "mynickname" est le propriétaire du dossier / media / a_folder et dispose des autorisations rwx.

J'ai regardé de nombreuses discussions sur Internet sur des personnes ayant des problèmes assez similaires, mais rien n'a fonctionné jusqu'à présent. Habituellement, les gens ne peuvent même pas faire

sshfs my-PC:/a_folder /media/a_folder

sans obtenir une erreur, alors que cela fonctionne bien sur mon ordinateur portable.

Tout aperçu et conseils seront grandement appréciés! Merci.

EDIT: J'ai résolu ce problème il y a quelque temps, mais j'ai oublié de mettre à jour ce message. Voici donc ce qui est dans mon fstab:

sshfs#mynickname@my-PC:/a_folder /media/a_folder fuse noauto,_netdev,idmap=user,user,default_permissions 0 0

L'option clé à ajouter était default_permissions si je me souviens. J'ai dû ajouter mynickname au groupe auquel appartient / a_folder / sur mon PC.

fstab  sshfs 

Réponses:


8

Le problème que vous rencontrez est que votre utilisateur normal a une configuration correcte pour votre fichier d'identité, tandis que l'utilisateur root n'a aucune idée de la clé ssh à utiliser.

Vous pouvez résoudre ce problème en indiquant à fstab quel fichier d'identité / clé ssh utiliser lors de la connexion:

sshfs#user@host:/mnt/whatever/ /mnt/whatever/        fuse    user,_netdev,reconnect,uid=1000,gid=1000,IdentityFile=/home/USER/.ssh/KEYFILE,idmap=user,allow_other  0   2

Merci pour votre réponse. J'ai déjà essayé avec l'option IdentityFile, mais je n'ai pas spécifié les options uid et gid, donc je vais essayer ça!

Techniquement, vous ne devriez pas avoir besoin de l'utiliser sudosi tout est correctement configuré pour un montage FUSE. De plus, les paramètres uid / gid ne devraient affecter que l'utilisateur qui a des droits sur les fichiers de votre système.
earthmeLon

J'ai donc essayé avec uid, gid, IdentityFile, allow_other, toutes ces options en même temps, et malheureusement cela ne fonctionne toujours pas. Toujours la même erreur.

Pourriez-vous publier un échantillon de la façon dont vous l'avez écrit? Vous devez pointer vers votre clé privée et non votre clé publique.
earthmeLon

1
Les deux méthodes n'ont donc pas fonctionné. Toujours la même erreur. Pour le fichier de configuration, j'ai essayé en spécifiant pour le bon hôte: utilisateur, nom d'hôte (essayé à la fois IP et nom), fichier d'identité. Mais cela n'a pas fonctionné aussi bien. Donc, ce que je fais pour l'instant, c'est que j'ai ajouté la commande sshfs my-PC: / a_folder / media / a_folder dans les applications de démarrage. Ce n'est pas aussi propre que d'utiliser fstab, mais cela fonctionne assez bien pour l'instant. Merci pour votre aide et vos suggestions! Si vous pensez à autre chose, n'hésitez pas à partager, j'apprécierai!

4

Pour obtenir une sortie de débogage réelle, vous devez ajouter les options sshfs_debuget les debugoptions au montage:

sshfs#mynickname@my-PC:/a_folder /media/a_folder fuse defaults,idmap=user,_netdev,debug,sshfs_debug 0 0

Avec cela, vous obtiendrez beaucoup d'informations de débogage pour vous aider:

$ sudo mount -a
SSHFS version 2.5
FUSE library version: 2.9.2
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0
executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-2> <user@box> <-s> <sftp>
user@box's password: 
Server version: 3
Extension: posix-rename@openssh.com <1>
Extension: statvfs@openssh.com <2>
Extension: fstatvfs@openssh.com <2>
Extension: hardlink@openssh.com <1>
Extension: fsync@openssh.com <1>
unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
INIT: 7.22
flags=0x0000f7fb
max_readahead=0x00020000
remote_uid = 1001
   INIT: 7.19
   flags=0x00000011
   max_readahead=0x00020000
   max_write=0x00020000
   max_background=0
   congestion_threshold=0
   unique: 1, success, outsize: 40
unique: 2, opcode: STATFS (17), nodeid: 1, insize: 40, pid: 2771
unique: 3, opcode: LOOKUP (1), nodeid: 1, insize: 47, pid: 3371

Dans mon cas, j'ai découvert que ma machine n'était répertoriée que dans .ssh/config, donc il n'était pas résolu pour root.

Et BTW, vous devez définir uid et gid, car cela idmap=userne semble fonctionner que pour l'utilisateur actuel, qui est root dans ce cas.


3

Ce problème peut également se produire lorsque la clé d'hôte de ssh change.

Essayez de vous connecter au serveur via ssh (par exemple ssh username@hostIP). Si l'erreur suivante apparaît:

 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!    @
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Suivez les instructions du message d'erreur pour supprimer l'ancienne clé et essayez de vous reconnecter via ssh. Si l'erreur n'apparaît plus, la connexion sshfs devrait fonctionner.


"essayez de vous connecter au serveur via ssh" Assurez-vous de le faire en tant que root si vous montez le répertoire en tant que root (ce qui se produit lors du montage automatique). Le known_hostsfichier d' un utilisateur peut être différent du known_hostsfichier racine .
Shelvacu

0

Divulgation complète: geek à l'ancienne, mais flambant neuf dans le monde Linux / open source

Tout d'abord, j'utilise toujours l'authentification par mot de passe car je ne suis pas encore assez averti avec les clés RSA. C'est pourtant en haut de la liste.

Informations de configuration pertinentes: utilisation d'un MacBook Pro avec VMWare Fusion installé, sur lequel j'ai le serveur Ubuntu 10.04 LTS. S'appuyant sur le terminal Mac et SSH pour presque toutes mes interactions avec le serveur

Après avoir raté une installation Drupal, je suis revenu à un instantané précédent et j'ai soudainement été incapable d'exécuter une commande que je venais d'utiliser quelques instants auparavant: sshfs -o idmap=user -o allow_other user@mac.home:/Users/<username>/Documents ~/mountpoint

Le problème est que les clés ne sont plus synchronisées. Je ne sais pas si j'avais réellement besoin de le faire à la fois sur mon hôte et sur mon serveur, mais j'ai effacé toutes les clés locales sur chacune en faisant d'abord une sauvegarde du fichier known_hosts, puis en modifiant le fichier known_hosts pour supprimer les entrées .
Sur Mac, ce fichier se trouve dans: /Users/<username>/.ssh/known_hosts
Sur Ubuntu, ce fichier se trouve dans:/home/<username>/.ssh/known_hosts

Donc, pour résumer, tout a été effectué à partir de mon terminal Mac, après le démarrage du serveur Ubuntu:

cp /Users/<username>/.ssh/known_hosts /Users/<username>/.ssh/known_hosts.old
nano  /Users/<username>/.ssh/known_hosts
  # remove extra entries, save file
ssh <username>@ubuntu_server
cp /home/<username>/.ssh/known_hosts, /home/<username>/.ssh/known_hosts.old
nano /home/<username>/.ssh/known_hosts
  # remove extra entries, save file

Lors de la première connexion SSH dans chaque système, SSH me demande d'autoriser l'ajout de clés RSA et tous les travaux par la suite.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.