SSH Permission denied

Le
unbewusst.sein
côté client, j'utilise OpenSSH _5.0p1 et côté serveur dropbear 0.5 (tél
portable)

côté client si je suis loggué en root ($ su root) pas de pb pour accéder
à mon portable par :
root$ ssh -l -v -v -v -p 2222 root@169.254.0.2
[]
Enter passphrase for key '/var/root/.ssh/id_dsa':
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).


bien dévidemment, je préfère rester en user, et là, ça bloque :
$ ssh -l -v -v -v -p 2222 root@169.254.0.2
[]
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/yt/.ssh/identity
debug1: Trying private key: /Users/yt/.ssh/id_rsa
debug1: Offering public key: /Users/yt/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
debug1: No more authentication methods to try.
Permission denied (publickey).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^

par contre, si j'utilise ssh-agent, je n'ai pas de problème pour me
connecter, partie du script concerné :

authentification:
authent() {
ssh-agent >$MY_SSH_AGENT_INFO # ~/.ssh/tt-ssh-agent-info
chmod 600 $MY_SSH_AGENT_INFO
source $MY_SSH_AGENT_INFO >/dev/null
ssh-add $MY_SSH_KEY # ~/.ssh/id_dsa
}

connection ssh :
authent
ssh -p 2222 root@$IP_TT # 169.254.0.2


donc deux choses que je ne comprends pas :

- pourquoi ça marche impec avec ssh-agent et pas sans lui avec la même
passphrase ?

- pourquoi ça marche toujours quand je suis loggué en root côté client

sur le tél portable, on est quasiment tjs en root
--
Une Bévue
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
unbewusst.sein
Le #16409401
Loic Tortay
La clef présentée n'a pas été acceptée, le client passe à la méthode
d'authentification suivante (puisqu'il n'y a semble-t-il qu'une clef
proposée).

Comme il n'y a pas d'autre méthode d'authentification disponible,
l'authentification échoue.



je n'ai qu'une clé dsa par login, donc une pour root une pour yt.
elles sont différentes, avec même passphrase.

Est-ce que les clefs "/var/root/.ssh/id_dsa" et "/Users/yt/.ssh/id_dsa"
sur le client sont les mêmes, si ce n'est pas le cas est-ce que la
deuxième clef est autorisée sur la destination ? (manifestement non)



elles sont différentes, les deux clés sont bien dans mon fichier
"authorized_keys" côté serveur.
il y en a une par ligne.
vérifié par vi.

La clef publique de tous les couples de clefs utilisés doit être dans
le fichier "~root/.ssh/authorized_keys" (ou équivalent) sur la
destination.



oui, elles y sont.
sinon aurais-je pu me connecter, depuis mon compte "yt" en utilisant
ssh-agent ?
c'est une des choses que je ne comprends pas, pourquoi ça marche (en
tant que user "yt") en utilisant ssh-agent, et que, sans lui, ssh ne me
demande même pas la passphrase ?

Une seule clef par ligne, pour détecter les erreurs de copier/coller
ou de syntaxe, vérifier le contenu du fichier "authorized_keys" de la
destination avec la commande : "ssh-keygen -lf authorized_keys".



bon, comme je n'ai pas trouvé la commande "ssh-keygen" sur mon tél
portable, j'ai rapatrié "authorized_keys" sur mon mac :
$ ssh-keygen -lf authorized_keys
1024 7a:c7:22:70:7a:fe:d0:2b:e6:20:08:64:b6:5b:84:6f authorized_keys

notez que la page de man "ssh-keygen" donne bien l'option -l chez moi,
mais ne la documente pas.
--
Une Bévue
unbewusst.sein
Le #16410001
Loic Tortay
Est-ce que c'est la bonne/même clef qui est chargée dans l'agent ?

Pour le savoir, il faut utiliser la commande "ssh-add -l" qui donne les
« fingerprints » des clefs chargées dans l'agent.


$ ssh-add -l
Could not open a connection to your authentication agent.

par contre :
$ ps -ax | grep ssh-agent | grep -v grep
429 ?? Ss 0:00.14 ssh-agent

alors j'ai ajouté une function "list" à mon script (zsh) qui gère la
connection avec cet ssh-agent qui est bien running :
$ ./ssh_connect.zsh list
1024 17:e6:02:16:bc:f3:c2:a2:0a:26:ef:0a:6f:51:8f:61
/Users/yt/.ssh/id_dsa (DSA)

$ ssh-keygen -lf ~/.ssh/id_dsa.pub
1024 6b:f6:76:34:75:da:0c:ff:c4:58:43:b6:9f:12:32:99
/Users/yt/.ssh/id_dsa.pub

euh, c'est le bronx là, pas le mêm fingerprint...

maintenant, j'ai garde trace de mon keygen :
$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/Users/yt/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/yt/.ssh/id_dsa.
Your public key has been saved in /Users/yt/.ssh/id_dsa.pub.
The key fingerprint is:
17:e6:02:16:bc:f3:c2:a2:0a:26:ef:0a:6f:51:8f:61

donc c'est la première qui est la bonne...

après un cat de ~/.ssh/id_dsa.pub, je vois deux clès, je supprime la
première et :

$ ssh-keygen -lf ~/.ssh/id_dsa.pub
1024 17:e6:02:16:bc:f3:c2:a2:0a:26:ef:0a:6f:51:8f:61
/Users/yt/.ssh/id_dsa.pub

il y a accord maintenant, résultat :

$ ssh -p 2222
Enter passphrase for key '/Users/yt/.ssh/id_dsa':
_______ _______ _______ _______ _______ __ _______
| || | |__ __|| _ || _ || | | ____|
|__ __||__ __| ___ | | | |_| || |_| || |____ |____ |
| | | | |___| |_| |_______||_______||_______||_______|
|_| |_| Bienvenue sur le Twin Tact !!!
Last login: Fri Jul 25 14:06:23 UTC 2008
# ls
NVS bin db idex
system voice
app config dhcpc log
usr wifi
app_data dar_20071104_143132 ffs ppp
usr_data
apps data hosts sbin
var
# exit
Connection to 169.254.0.2 closed.


OUFFFFF ! merci beaucoup, je comprend pourquoi ça marcchait sous root et
pas yt, sous root je n'avais pas ajouté cette clé ** en trop ** dans
l'équivalent de /Users/yt/.ssh/id_dsa ...

Il suffit alors de comparer avec le résultat de la commande :
"ssh-keygen -lf ~yt/.ssh/id_dsa.pub".


> > Une seule clef par ligne, pour détecter les erreurs de copier/coller
> > ou de syntaxe, vérifier le contenu du fichier "authorized_keys" de la
> > destination avec la commande : "ssh-keygen -lf authorized_keys".
>
> bon, comme je n'ai pas trouvé la commande "ssh-keygen" sur mon tél
> portable, j'ai rapatrié "authorized_keys" sur mon mac :
> $ ssh-keygen -lf authorized_keys
> 1024 7a:c7:22:70:7a:fe:d0:2b:e6:20:08:64:b6:5b:84:6f authorized_keys
>
Là, il n'y a qu'une clef publique, pas deux.

"ssh-keygen -l" affiche une ligne par clef publique.



bon, donc il y a un autre pb à résoudre si je fais un cat du fichier
"authorized_keys" j'ai :

$ cat authorized_keys
#
# Exemple de clé publique à insérer: décommenter pour permettre à
Tequila
# d'accéder à votre téléphone quand il est dans le même réseau wifi où
si vous
# obtenez une adresse publique et que vous lui demandez d'accédez à
votre TwinTact
#
# Vous trouverez votre clef publique à insérer ici dans votre fichier
~/.ssh/id_dsa.pub
# Si ce fichier n'existe pas lancez la commande ssh-keygen -t dsa pour
le créer
# Cette méthode est la plus sûre pour accéder à votre TwinTact
#
ssh-dss AAAAB3NzaC1kc3MAAACBAP...<! snip -->...DfFf


ssh-dss AAAAB3NzaC1kc3MAAACBAK...<! snip -->...ye7A== tequila

ssh-dss AAAAB3NzaC1kc3MAAACBAJ...<! snip -->...J0g==

(tequila a été créé à l'install de dropbear)

donc j'ai bien 3 clés :
tequila, root et yt non ?

soit dit, en passant, je ne sais ce qu'est tequila...

en tk, merci bien j'ai pigé qqc...
--
Une Bévue
unbewusst.sein
Le #16410391
Loic Tortay
J'ai oublié que certaines vieilles versions de "ssh-keygen" n'affichent
que la première clef du fichier.




OK, merci !

aussi ma "bévue" signifie aussi que le chargement de la clé ne se fait
pas de la même manière en direct ou avec ssh-agent et ssh-add.

la première manière ne voyant que la première clé, qui n'était pas la
bonne ;
la seconde testerait les différentes clés et fini par trouver la seconde
OK ???

[...]


<snip />
>
> donc j'ai bien 3 clés :
> tequila, root et yt non ?
>
Oui.

> soit dit, en passant, je ne sais ce qu'est tequila...
>
Il suffit de désactiver la clef en la commentant ("#" au début de la
ligne) ou en la supprimant.



ou de chercher à savoir à quoi peut bien servir tequila, une odeur de
coktail ?
;-)

car j'aimerais bien faire du ssh à tavers le WiFi plutôt qu'avec le
cordon USB...
--
Une Bévue
Publicité
Poster une réponse
Anonyme