#1 Le 07/07/2010, à 15:25
- Menestrel
[Résolu] Problème avec l'utilisation de ssh sans password
Bonjour à tous,
Déjà c'est la première fois que je poste un message sur ce forum, merci de me corriger si je commets un impair.
Ensuite voici mon problème.
Je suis en train de configurer une installation de Hadoop (un framework d'Apache pour utiliser une architecture distribuée, mais osef).
Le point important : pour utiliser ce framework, les machines ont beson de communiquer entre-elles et pour ce faire elles doivent passer par OpenSSH. Jusque là pas de problème.
Comme le but n'est pas d'avoir un admin en permanence devant la console à valider toutes les transactions entre les machines, il est nécessaire de générer une clef ssh pour chaque machine et de partager les clefs publiques (sans passphrase sinon on manque le but recherché, évidemment). Toujours pas de problème.
Seulement voilà, j'ai à ma disposition plusieurs machines différentes pour faire des tests (entre autre du windows server avec cygwin, du redHat, etc..) et l'une d'elle refuse obstinément la communication sans password.
Cette machine est sous OpenSuse pour info, mais à priori ce n'est pas lié puisque OpenSSH n'a rien de spécifique à une distribution (même les windows server l'utilisent sans problème...). Je sais bien que c'est un forum Ubuntu ici, mais jusqu'ici c'est aussi ma meilleure référence question Linux.
Voici les étapes par lesquelles je passe pour créer ma clef :
ssh-keygen -t dsa -P -f id_dsa #J'ai essayé de changer pour rsa mais pas d'amélioration
cat ~/.ssh/id_dsa.pub | ssh localhost 'cat >> ~/.ssh/authorized_keys #ici j'ai aussi essayé de changer pour authorized_keys2, sans effet
Malgré ça, une tentative de connexion "ssh localhost" me demande toujours un Password.
J'ai vu plusieurs fois conseillé de surveiller les permissions de .ssh et des fichiers dedans, ce que j'ai fait (700 pour .ssh, 600 pour .ssh/id_dsa, etc...).
En désespoir de cause j'ai tenté de lancer ssh en mode verbeux histoire de voir si j'arrivais à décrypter ce qu'il se passe, mais ça reste hélas du chinois :
albert@yoda:~/.ssh> ssh -v localhost
OpenSSH_4.1p1, OpenSSL 0.9.7g 11 Apr 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /opt/amibench/.ssh/identity type -1
debug1: identity file /opt/amibench/.ssh/id_rsa type -1
debug1: identity file /opt/amibench/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.1
debug1: match: OpenSSH_4.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /opt/amibench/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /opt/amibench/.ssh/identity
debug1: Trying private key: /opt/amibench/.ssh/id_rsa
debug1: Offering public key: /opt/amibench/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Password:
Voilà, j'espère que quelqu'un aura des idées (ou mieux, une solution !) sur ce qui cloche. Je continue à chercher de mon côté mais j'ai un peu l'impression d'arriver au bout de ce que je connais (ce qui est très frustrant ).
Merci d'avance.
Dernière modification par Menestrel (Le 08/07/2010, à 15:53)
Hors ligne
#2 Le 07/07/2010, à 18:43
- Ennely
Re : [Résolu] Problème avec l'utilisation de ssh sans password
Le problème était simple a identifier, mais a résoudre un peu moins
debug1: Authentications that can continue: publickey,password,keyboard-interactive
...
debug1: Next authentication method: keyboard-interactive
En comparant avec tes autres machines tu te serais rendu compte qu'elles n'utilisent pas la methode "keyboard-interactive"
Pour desactiver cette methode d'authentification ca se passe dans:
/etc/ssh/sshd_config
ligne:
ChallengeResponseAuthentication no
Hors ligne
#3 Le 08/07/2010, à 09:49
- Menestrel
Re : [Résolu] Problème avec l'utilisation de ssh sans password
Salut Ennely, merci de bien vouloir m'aider.
Malheureusement rajouter cette ligne n'est pas suffisant. Effectivement on ne passe plus par une méthode "keyboard-interactive", mais la clef publique n'est pas acceptée pour autant (et on retombe sur une authentification par password standard).
Du coup j'ai vérifié les fichiers de configuration de ssh et sshd (merci du coup de main, j'ignorais totalement leur existence) et... ben je ne vois toujours pas ce qui cloche.
En comparant avec les autres machines comme tu l'as conseillé, je me rends compte que je propose bien au serveur ma clef publique :
debug1: Offering public key: /opt/amibench/.ssh/id_dsa
...mais le serveur n'a pas l'air de la reconnaitre comme une clef autorisée (alors qu'elle est bien dans le fichier ~/.ssh/authorized_keys).
Le fichier de configuration me paraît bon :
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
Je continue à chercher mais c'est désespérant... J'aimerais bien avoir au moins une sortie verbeuse côté serveur, ça m'aiderait peut-être, mais je ne vois pas comment faire.
En tout cas merci pour ton aide, je progresse.
Hors ligne
#4 Le 08/07/2010, à 13:47
- mael78
Re : [Résolu] Problème avec l'utilisation de ssh sans password
pour sshd en mode debug tu change
LogLevel INFO
en
LogLevel DEBUG
dans
/etc/ssh/sshd_config
regarde dans man sshd_config
LogLevel
Gives the verbosity level that is used when logging messages from
sshd(8). The possible values are: SILENT, QUIET, FATAL, ERROR,
INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is
INFO. DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each
specify higher levels of debugging output. Logging with a DEBUG
level violates the privacy of users and is not recommended.
---------------------“In the Beginning...was the Command Line”----------------------
HTPC athlon64 x2 4000+/GF GT430/Auzen X-Plosion/2GO DDR2 sous LiveXBMC
Desktop Corei7 920/GF GTX560TI/3GO DDR3 sous multiboot Ubuntu 11.10(Cinnamon)/Seven
Laptop Acer Turion64 x2/Mobility Radeon X1300/2 GO DDR2 sous Mint 12 LXDE
Hors ligne
#5 Le 08/07/2010, à 14:56
- Menestrel
Re : [Résolu] Problème avec l'utilisation de ssh sans password
Salut mael78, et merci de ton aide
Grâce à toi j'ai pu afficher les logs de sshd et finalement observer que
Authentication refused: bad ownership or modes for directory /usr/local/opt/amibench
(qui est en fait mon home)
En changeant les permission pour 755, j'ai alors finalement réussi à me connecter, sans mot de passe, sans problème.
Merci beaucoup pour votre aide à tous les deux, et la conclusion donc : le dossier personnel lui-même ne doit pas être writable pour pouvoir utiliser une authentification à clef publique avec ssh.
Merci encore, je change le titre pour "résolu" tout de suite.
Bonne journée.
Dernière modification par Menestrel (Le 08/07/2010, à 16:06)
Hors ligne
#6 Le 08/07/2010, à 19:08
- mael78
Re : [Résolu] Problème avec l'utilisation de ssh sans password
roohh un probléme de droit!!! ça m'arrive tt le temps !!!!:lol::lol::lol:
---------------------“In the Beginning...was the Command Line”----------------------
HTPC athlon64 x2 4000+/GF GT430/Auzen X-Plosion/2GO DDR2 sous LiveXBMC
Desktop Corei7 920/GF GTX560TI/3GO DDR3 sous multiboot Ubuntu 11.10(Cinnamon)/Seven
Laptop Acer Turion64 x2/Mobility Radeon X1300/2 GO DDR2 sous Mint 12 LXDE
Hors ligne