sshfs n'utilisera pas ~ / .ssh / config (sous Linux Mint 15)

Local: Linux Mint 15 - Olivia /proc/version: Linux version 3.8.0-19-generic (buildd@allspice) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) ssh -V: OpenSSH_6.1p1 Debian-4, OpenSSL 1.0.1c 10 May 2012 sshfs -V: SSHFS version 2.4 FUSE library version: 2.9.0 fusermount version: 2.9.0 using FUSE kernel interface version 7.18 Remote: Ubuntu 12.04.3 LTS /proc/version: Linux version 3.10.9-xxxx-std-ipv6-64 ([email protected]) (gcc version 4.7.2 (Debian 4.7.2-5) ) ssh -V: OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012 

J'essaye de mettre en place un assembly sans mot de passe d'un server distant en utilisant sshfs et fusible. Le server distant s'exécute sur un port non standard et j'utiliserai une paire de keys ssh pour l'authentification.

En cas de succès, je le répéterai pour trois autres servers distants, chacun avec des keys différentes, donc je dois pouvoir spécifier quelles maps keys sur quel server distant.

J'ai basé mes modifications sur ce tutoriel

  • La key publique est dans remote: authorized_keys
  • J'ai ajouté mon user local au groupe de fuse .
  • J'ai édité mon ~/.ssh/config local pour avoir (par server):

`

 Host [server_ip] Port = [port] IdentityFile = "~/.ssh/[private_key]" User = "[user]" 

`

Chaque fois que j'essaie de monter le server distant localement, je suis invité à entrer le mot de passe de l'user distant (pas le mot de passe de ma key privée). L'user distant a un long mot de passe généré randomment que je ne voudrais pas avoir à save ou à mémoriser et donc les keys est comme je veux le faire.

Je peux me connecter via ssh (combiné avec le file ~/.ssh/config ) en utilisant la command ssh [ip] . Je sais que le file de configuration peut être lu correctement car on me request la phrase secrète de ma key et non celle de l'user distant.

Pour tenter de me connecter au server distant, je dois spécifier manuellement les détails de connection complets dans la command: `sshfs [user] @ [ip]: [path_distant] [path_local] -p [port]

Ce que j'ai essayé jusqu'à présent:

  • ssh-add / path / to / key (ajout réussi)
  • Spécification de PreferredAuthentication = publickey dans ~ / .ssh / config
  • sshfs -o IdentityFile = / path / vers / key user @ ip: / / mon / mnt / dir
  • sshfs user @ ip: / / mon / mnt / dir -o IdentityFile = / path / vers / key
  • renommer temp de key à la valeur par défaut de id_rsa
  • sshfs -F ~ / .ssh / config

Y a-t-il un file de configuration distant ou local que je néglige? Certains switch ou option que j'ai besoin d'inclure dans l'appel à sshfs (essayé -F) pour le forcer à lire et à utiliser ma config ssh?

Sortie de ssh -v -p [port] [user]@[remote_ip]

 OpenSSH_6.1p1 Debian-4, OpenSSL 1.0.1c 10 mai 2012
 debug1: Lecture des données de configuration /home/[me]/.ssh/config
 debug1: /home/[me]/.ssh/config ligne 2: application des options pour [remote_ip]
 debug1: /home/[me]/.ssh/config ligne 24: application d'options pour *
 debug1: Lecture des données de configuration / etc / ssh / ssh_config
 debug1: / etc / ssh / ssh_config ligne 19: application d'options pour *
 debug1: login à [remote_ip] [[remote_ip]] port [port].
 debug1: connection établie.
 debug1: file d'identité /home/[me]/.ssh/[private_key] type 2
 debug1: Vérification du file de la list noire /usr/share/ssh/blacklist.DSA-1024
 debug1: Vérification du file de la list noire /etc/ssh/blacklist.DSA-1024
 debug1: file d'identité /home/[me]/.ssh/[private_key]-cert type -1
 debug1: Protocole à distance version 2.0, version logicielle à distance OpenSSH_5.9p1 Debian-5ubuntu1.1
 debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH_5 *
 debug1: activation du mode de compatibilité pour le protocole 2.0
 debug1: Chaîne de la version locale SSH-2.0-OpenSSH_6.1p1 Debian-4
 debug1: SSH2_MSG_KEXINIT envoyé
 debug1: SSH2_MSG_KEXINIT a reçu
 debug1: kex: server-> client aes128-ctr hmac-md5 [email protected]
 debug1: kex: client-> server aes128-ctr hmac-md5 [email protected]
 debug1: envoi de SSH2_MSG_KEX_ECDH_INIT
 debug1: attente de SSH2_MSG_KEX_ECDH_REPLY
 debug1: Clé d'hôte du server: [key]
 debug1: vérification sans identificateur de port
 debug1: L'hôte '[remote_ip]' est connu et correspond à la key de l'hôte ECDSA.
 debug1: Clé trouvée dans /home/[me]/.ssh/known_hosts:7
 debug1: trouvé la key correspondante w / out port
 debug1: ssh_ecdsa_verify: signature correcte
 debug1: SSH2_MSG_NEWKEYS envoyé
 debug1: attend SSH2_MSG_NEWKEYS
 debug1: SSH2_MSG_NEWKEYS a reçu
 debug1: itinérance non autorisée par le server
 debug1: SSH2_MSG_SERVICE_REQUEST envoyé
 debug1: SSH2_MSG_SERVICE_ACCEPT reçu
 debug1: Authentifications qui peuvent continuer: publickey, mot de passe
 debug1: Méthode d'authentification suivante: publickey
 debug1: Offrant une key publique DSA: /home/[me]/.ssh/[private_key]
 debug1: Le server accepte la key: pkalg ssh-dss blen 433
 debug1: Activation de la compression au niveau 6.
 debug1: L'authentification a réussi (publickey).
 Authentifié sur [remote_ip] ([[remote_ip]]: [port]).
 debug1: canal 0: nouveau [session-client]
 debug1: Demande [email protected]
 debug1: Entrée de la session interactive.
 debug1: Environnement d'envoi.
 debug1: Envoi env LANG = en_GB.UTF-8
 debug1: Envoi env LC_CTYPE = en_GB.UTF-8
 Bienvenue sur Ubuntu 12.04.3 LTS (GNU / Linux 3.10.9-xxxx-std-ipv6-64 x86_64)

Modifier:
J'ai trouvé le problème. J'essayais de monter l'location distant dans / mnt / new_dir en utilisant sudo. Si je monte à un endroit dans ma maison locale alors cela fonctionne. sshfs -p [port] [user]@[ip]:/ /home/[me]/tmp/mount .

J'ai maintenant fait une sudo chown root:fuse /mnt/new_dir et sudo chmod 774 /mnt/new_dir et je crois que tout fonctionne comme prévu.

Y a-t-il des problèmes de security avec cette configuration dont je dois être conscient? (Mon propre user et la racine sont les seuls membres du groupe fuse .

Si vous utilisez sudo vous utilisez probablement les informations d'identification de root, ce que je ne crois pas est ce que vous voulez. Je ne ferais probablement pas ce que vous requestz, par contre. monter sur /mnt tant qu'user1 et accéder en tant qu'user2. Cela va se compliquer avec les groupes et les permissions des users. Si vous voulez vraiment monter un directory dans / mnt à partager, alors vous devriez vraiment le monter via le niveau système pour tous les autofs .

Automounting

Il y a 3 methods que je connais pour monter automatiquement une monture comme celle-ci.

  • autosshfs – Par user SSHFS automount utilisant la configuration et les keys SSH de l'user.
  • autofs – donne access aux filesystems à la request
  • afuse est un système de files de assembly automatique implémenté dans l'espace user à l'aide de FUSE.