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 (kernel@kernel.ovh.net) (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'essaie de configurer un montage sans mot de passe d'un serveur distant en utilisant sshfs et fuse. Le serveur distant fonctionne sur un port non standard et j'utiliserai une paire de clés ssh pour m'authentifier.
En cas de succès, je répéterai cela pour trois autres serveurs distants, chacun avec des clés différentes, je dois donc être en mesure de spécifier quelle clé correspond à quel serveur distant.
J'ai basé mes modifications sur ce tutoriel
- La clé publique est dans remote: authorized_keys
- J'ai ajouté mon utilisateur local au
fusegroupe. - J'ai édité mon local
~/.ssh/configpour avoir (par serveur):
"
Host [server_ip]
Port = [port]
IdentityFile = "~/.ssh/[private_key]"
User = "[user]"
"
Chaque fois que j'essaie de monter le serveur distant localement, on me demande le mot de passe de l'utilisateur distant (pas le mot de passe de ma clé privée). L'utilisateur distant a un long mot de passe généré aléatoirement que je ne voudrais pas avoir à enregistrer ou à mémoriser et donc les clés sont la façon dont je veux le faire.
Je peux me connecter via ssh (combiné avec le ~/.ssh/configfichier) en utilisant la commande ssh [ip]afin que je sache que le fichier de configuration peut être lu correctement car on me demande la phrase de passe de ma clé et non celle de l'utilisateur distant.
Pour même tenter de me connecter au serveur distant, je dois spécifier manuellement les détails de connexion complets dans la commande: `sshfs [user] @ [ip]: [remote_path] [local_path] -p [port]
Ce que j'ai essayé jusqu'à présent:
- ssh-add / chemin / vers / clé (ajout réussi)
- Spécification
PreferredAuthentication = publickeydans ~ / .ssh / config - sshfs -o IdentityFile = / chemin / vers / utilisateur clé @ ip: / / mon / mnt / dir
- sshfs user @ ip: / / my / mnt / dir -o IdentityFile = / chemin / vers / clé
- renommage temporaire de la clé par défaut
id_rsa - sshfs -F ~ / .ssh / config
Y a-t-il un fichier de configuration local ou distant que je regarde? Un commutateur ou une option que je dois inclure dans l'appel à sshfs (essayé -F) pour le forcer à lire et à utiliser ma configuration 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 E5E/.ssh/config ligne 2: application d'options pour [remote_ip] debug1: /home/[me E5E/.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: connexion au port [remote_ip] [[remote_ip]] [port]. debug1: connexion établie. debug1: fichier d'identité /home/}me[/.ssh/[private_key] type 2 debug1: Vérification du fichier de liste noire /usr/share/ssh/blacklist.DSA-1024 debug1: Vérification du fichier de liste noire /etc/ssh/blacklist.DSA-1024 debug1: fichier d'identité /home/[me[/.ssh/[private_key debug1: protocole distant version 2.0, version logicielle distante OpenSSH_5.9p1 Debian-5ubuntu1.1 debug1: correspondance: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH_5 * debug1: activation du mode de compatibilité pour le protocole 2.0 debug1: chaîne de version locale SSH-2.0-OpenSSH_6.1p1 Debian-4 debug1: SSH2_MSG_KEXINIT envoyé debug1: SSH2_MSG_KEXINIT reçu debug1: kex: serveur-> client aes128-ctr hmac-md5 zlib@openssh.com debug1: kex: client-> serveur aes128-ctr hmac-md5 zlib@openssh.com debug1: envoi de SSH2_MSG_KEX_ECDH_INIT debug1: attend SSH2_MSG_KEX_ECDH_REPLY debug1: clé d'hôte du serveur: [clé] debug1: vérification sans identifiant de port debug1: l'hôte '[remote_ip]' est connu et correspond à la clé d'hôte ECDSA. debug1: clé trouvée dans /home/[me[/.ssh/known_hosts:7 debug1: clé correspondante trouvée sans port debug1: ssh_ecdsa_verify: signature correcte debug1: SSH2_MSG_NEWKEYS envoyé debug1: attend SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS reçu debug1: Itinérance non autorisée par le serveur 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: offre de la clé publique DSA: /home/[me[/.ssh/[private_key] debug1: le serveur accepte la clé: pkalg ssh-dss blen 433 debug1: activation de la compression au niveau 6. debug1: authentification réussie (publickey). Authentifié auprès de [remote_ip] ([[remote_ip]]: [port]). debug1: canal 0: nouveau [client-session] debug1: Demande à no-more-sessions@openssh.com debug1: entrée dans une session interactive. debug1: Envoi de l'environnement. debug1: Envoi env LANG = en_GB.UTF-8 debug1: Envoi env LC_CTYPE = en_GB.UTF-8 Bienvenue dans Ubuntu 12.04.3 LTS (GNU / Linux 3.10.9-xxxx-std-ipv6-64 x86_64)
Edit:
j'ai trouvé le problème. J'essayais de monter l'emplacement distant sur / mnt / new_dir en utilisant sudo. Si je monte à un emplacement dans ma maison locale, cela fonctionne. sshfs -p [port] [user]@[ip]:/ /home/[me]/tmp/mount.
J'ai maintenant fait un sudo chown root:fuse /mnt/new_diret sudo chmod 774 /mnt/new_diret je crois que tout fonctionne comme prévu.
Y a-t-il des problèmes de sécurité avec cette configuration dont je dois être conscient? (Mon propre utilisateur et root sont les seuls membres du fusegroupe.
-o ssh_command='ssh -v'commande se bloque et ne produit rien
sshfs -p [port] [user]@[ip]:/ /home/[me]/tmp/mount. Puis-je configurer mon utilisateur afin qu'il dispose des autorisations nécessaires pour monter sur / mnt afin que d'autres utilisateurs puissent utiliser les ressources distantes?