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é :
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
unbewusst.sein
Loic Tortay wrote:
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
Loic Tortay <lusenet@bougon.net.invalid> wrote:
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
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
Loic Tortay wrote:
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)
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 -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
soit dit, en passant, je ne sais ce qu'est tequila...
en tk, merci bien j'ai pigé qqc... -- Une Bévue
Loic Tortay <lusenet@bougon.net.invalid> wrote:
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)
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 yt@www.une-bevue.fr
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 -p 2222 root@169.254.0.2
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
root@www.une-bevue.fr
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)
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 -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
soit dit, en passant, je ne sais ce qu'est tequila...
en tk, merci bien j'ai pigé qqc... -- Une Bévue
unbewusst.sein
Loic Tortay wrote:
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
Loic Tortay <lusenet@bougon.net.invalid> wrote:
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
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
