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