Config ssh pour authentification par clé avec client cygwin
8 réponses
Lassie
Hello,
J'ai un petit problème sur une machine qui fait tourner un serveur sshd
(Mandrake 10.1) :
A partir d'un client sous Windows (et voui... snif... pas le choix...),
j'ai installé Cygwin avec son package ssh qui va bien
Je peux me connecter sans problème au serveur ssh à partir du client
sous cygwin à partir du moment ou je tape mon mot de passe. Donc ça
c'est bon.
Maintenant, j'aurai voulu rajouter une authentification par clé et c'est
là que ça coince :
- génération les clés publiques et privées sous cygwin avec la commande
ssh-keygen -t <type> (dsa, rsa, et rsa1)
- transfert des clés publiques (.pub) par sftp (en me connectant avec
mon mot de passe).
- sur le serveur, dans le fichier sshd_config : je rajoute :
RSAAuthentication yes
ChallengeResponseAuthentication yes
- sur le serveur, dans mon compte, je rajoute les clés publiques dans le
fichier authorized_keys
- re-démarrage du serveur ssh
Et quand je veux me connecter, il me re-demande mon mot de passe, comme
s'il ne reconnaissait aucune des trois clés publiques.
Est-ce que ça peut venir du fait que les cles sont générées sous cygwin
? Quelqu'un a déjà eu ce problème ?
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
TiChou
Dans le message <news:422f166a$0$2447$, *Lassie* tapota sur f.c.o.l.configuration :
Hello,
Bonjour,
J'ai un petit problème sur une machine qui fait tourner un serveur sshd (Mandrake 10.1) :
j'aurai voulu rajouter une authentification par clé et c'est là que ça coince : - génération les clés publiques et privées sous cygwin avec la commande ssh-keygen -t <type> (dsa, rsa, et rsa1)
Quel type avez-vous utilisé au final ?
- transfert des clés publiques (.pub) par sftp (en me connectant avec mon mot de passe). - sur le serveur, dans le fichier sshd_config : je rajoute : RSAAuthentication yes ChallengeResponseAuthentication yes
Par défaut ces options sont à yes, il n'était donc pas forcément utile de les rajouter. Par contre, quelles sont les autres options qui sont renseignées dans ce fichier ?
- sur le serveur, dans mon compte, je rajoute les clés publiques dans le fichier authorized_keys - re-démarrage du serveur ssh
Et quand je veux me connecter, il me re-demande mon mot de passe, comme s'il ne reconnaissait aucune des trois clés publiques.
C'est bien le mot de passe qu'il vous demande et non pas la « passphrase » ?
Dans tous les cas, vérifiez les logs du serveur SSH, il vous indiquera très certainement la raison du refus d'authentification par clé.
Est-ce que ça peut venir du fait que les cles sont générées sous cygwin ?
Non, du tout.
Quelqu'un a déjà eu ce problème ?
On peut rencontrer ce problème en voulant par exemple utiliser une clé DSA sur un serveur SSH utilisant le protocole version 1. Mais plus généralement on rencontre ce problème quand les permissions sur le répertoire ~/.ssh sont incorrectes.
$ chmod 0700 ~/.ssh ; chmod 0600 ~/.ssh/*
-- TiChou
Dans le message <news:422f166a$0$2447$626a14ce@news.free.fr>,
*Lassie* tapota sur f.c.o.l.configuration :
Hello,
Bonjour,
J'ai un petit problème sur une machine qui fait tourner un serveur sshd
(Mandrake 10.1) :
j'aurai voulu rajouter une authentification par clé et c'est là que ça
coince :
- génération les clés publiques et privées sous cygwin avec la commande
ssh-keygen -t <type> (dsa, rsa, et rsa1)
Quel type avez-vous utilisé au final ?
- transfert des clés publiques (.pub) par sftp (en me connectant avec mon
mot de passe).
- sur le serveur, dans le fichier sshd_config : je rajoute :
RSAAuthentication yes
ChallengeResponseAuthentication yes
Par défaut ces options sont à yes, il n'était donc pas forcément utile de
les rajouter.
Par contre, quelles sont les autres options qui sont renseignées dans ce
fichier ?
- sur le serveur, dans mon compte, je rajoute les clés publiques dans le
fichier authorized_keys
- re-démarrage du serveur ssh
Et quand je veux me connecter, il me re-demande mon mot de passe, comme
s'il ne reconnaissait aucune des trois clés publiques.
C'est bien le mot de passe qu'il vous demande et non pas la
« passphrase » ?
Dans tous les cas, vérifiez les logs du serveur SSH, il vous indiquera très
certainement la raison du refus d'authentification par clé.
Est-ce que ça peut venir du fait que les cles sont générées sous cygwin ?
Non, du tout.
Quelqu'un a déjà eu ce problème ?
On peut rencontrer ce problème en voulant par exemple utiliser une clé DSA
sur un serveur SSH utilisant le protocole version 1.
Mais plus généralement on rencontre ce problème quand les permissions sur le
répertoire ~/.ssh sont incorrectes.
Dans le message <news:422f166a$0$2447$, *Lassie* tapota sur f.c.o.l.configuration :
Hello,
Bonjour,
J'ai un petit problème sur une machine qui fait tourner un serveur sshd (Mandrake 10.1) :
j'aurai voulu rajouter une authentification par clé et c'est là que ça coince : - génération les clés publiques et privées sous cygwin avec la commande ssh-keygen -t <type> (dsa, rsa, et rsa1)
Quel type avez-vous utilisé au final ?
- transfert des clés publiques (.pub) par sftp (en me connectant avec mon mot de passe). - sur le serveur, dans le fichier sshd_config : je rajoute : RSAAuthentication yes ChallengeResponseAuthentication yes
Par défaut ces options sont à yes, il n'était donc pas forcément utile de les rajouter. Par contre, quelles sont les autres options qui sont renseignées dans ce fichier ?
- sur le serveur, dans mon compte, je rajoute les clés publiques dans le fichier authorized_keys - re-démarrage du serveur ssh
Et quand je veux me connecter, il me re-demande mon mot de passe, comme s'il ne reconnaissait aucune des trois clés publiques.
C'est bien le mot de passe qu'il vous demande et non pas la « passphrase » ?
Dans tous les cas, vérifiez les logs du serveur SSH, il vous indiquera très certainement la raison du refus d'authentification par clé.
Est-ce que ça peut venir du fait que les cles sont générées sous cygwin ?
Non, du tout.
Quelqu'un a déjà eu ce problème ?
On peut rencontrer ce problème en voulant par exemple utiliser une clé DSA sur un serveur SSH utilisant le protocole version 1. Mais plus généralement on rencontre ce problème quand les permissions sur le répertoire ~/.ssh sont incorrectes.
$ chmod 0700 ~/.ssh ; chmod 0600 ~/.ssh/*
-- TiChou
TiChou
Dans le message <news:, *TiChou* tapota sur f.c.o.l.configuration :
[...]
J'ai oublié de dire d'utiliser avec la commande ssh l'option -v, -vv ou -vvv pour rendre ssh bavard et rapporter tous les messages utiles pour débugger le problème.
-- TiChou
Dans le message <news:bzium.20050309163414@florizarre.tichou.org>,
*TiChou* tapota sur f.c.o.l.configuration :
[...]
J'ai oublié de dire d'utiliser avec la commande ssh l'option -v, -vv ou -vvv
pour rendre ssh bavard et rapporter tous les messages utiles pour débugger
le problème.
Dans le message <news:, *TiChou* tapota sur f.c.o.l.configuration :
[...]
J'ai oublié de dire d'utiliser avec la commande ssh l'option -v, -vv ou -vvv pour rendre ssh bavard et rapporter tous les messages utiles pour débugger le problème.
-- TiChou
Philippe Delsol
Hello,
J'ai un petit problème sur une machine qui fait tourner un serveur sshd (Mandrake 10.1) : A partir d'un client sous Windows (et voui... snif... pas le choix...), j'ai installé Cygwin avec son package ssh qui va bien
Au cas où ... La solution client ssh Putty fonctionne très bien.
-- Philippe
Hello,
J'ai un petit problème sur une machine qui fait tourner un serveur sshd
(Mandrake 10.1) :
A partir d'un client sous Windows (et voui... snif... pas le choix...),
j'ai installé Cygwin avec son package ssh qui va bien
Au cas où ... La solution client ssh Putty fonctionne très bien.
J'ai un petit problème sur une machine qui fait tourner un serveur sshd (Mandrake 10.1) : A partir d'un client sous Windows (et voui... snif... pas le choix...), j'ai installé Cygwin avec son package ssh qui va bien
Au cas où ... La solution client ssh Putty fonctionne très bien.
-- Philippe
Lassie
TiChou wrote: (snip)
j'aurai voulu rajouter une authentification par clé et c'est là que ça coince : - génération les clés publiques et privées sous cygwin avec la commande ssh-keygen -t <type> (dsa, rsa, et rsa1)
Quel type avez-vous utilisé au final ?
Euh... les trois ! :-) J'ai mis les trois clés publiques dans le fichier authorized_keys (avec un cat key.pub >> authorized_keys)
Par défaut ces options sont à yes, il n'était donc pas forcément utile de les rajouter. Par contre, quelles sont les autres options qui sont renseignées dans ce fichier ?
Pour LogLevel, c'est moi qui ait essayé DEBUG, mais je ne vois rien de plus dans les traces après avoir redémarré le serveur
- sur le serveur, dans mon compte, je rajoute les clés publiques dans le fichier authorized_keys - re-démarrage du serveur ssh
Et quand je veux me connecter, il me re-demande mon mot de passe, comme s'il ne reconnaissait aucune des trois clés publiques.
C'est bien le mot de passe qu'il vous demande et non pas la « passphrase » ?
Oui, c'est bien le mot de passe du compte distant qu'il me demande.
Dans tous les cas, vérifiez les logs du serveur SSH, il vous indiquera très certainement la raison du refus d'authentification par clé.
Je n'arrive pas à avoir plus d'infos dans les logs du serveur. J'ai pourtant rajouté LogLevel DEBUG dans le fichier de config, mais ça ne change rien. Tout ce que j'ai au moment de la connection c'est ça :
Mar 10 08:15:11 mdk_server sshd[3126]: Connection from ::ffff:193.50.21.121 port 42811 Mar 10 08:15:11 mdk_server sshd[3126]: Failed none for lassie from ::ffff:193.50.21.121 port 42811 ssh2 Mar 10 08:15:13 mdk_server sshd[3126]: Accepted password for lassie from ::ffff:193.50.21.121 port 42811 ssh2 Mar 10 08:15:17 mdk_server sshd[3134]: Connection closed by ::ffff:193.50.21.121 Mar 10 08:15:17 mdk_server sshd[3134]: Closing connection to ::ffff:193.50.21.121
On peut rencontrer ce problème en voulant par exemple utiliser une clé DSA sur un serveur SSH utilisant le protocole version 1. Mais plus généralement on rencontre ce problème quand les permissions sur le répertoire ~/.ssh sont incorrectes.
$ chmod 0700 ~/.ssh ; chmod 0600 ~/.ssh/*
Voui, j'avais déjà regardé, mais ça ne change rien, il me demande toujours mon password. J'ai essayé de faire une chmod 755 aussi, mais pareil.
Merci pour les pistes en tout cas.
A+
TiChou wrote:
(snip)
j'aurai voulu rajouter une authentification par clé et c'est là que ça
coince :
- génération les clés publiques et privées sous cygwin avec la
commande ssh-keygen -t <type> (dsa, rsa, et rsa1)
Quel type avez-vous utilisé au final ?
Euh... les trois ! :-)
J'ai mis les trois clés publiques dans le fichier authorized_keys (avec
un cat key.pub >> authorized_keys)
Par défaut ces options sont à yes, il n'était donc pas forcément utile
de les rajouter.
Par contre, quelles sont les autres options qui sont renseignées dans ce
fichier ?
Pour LogLevel, c'est moi qui ait essayé DEBUG, mais je ne vois rien de
plus dans les traces après avoir redémarré le serveur
- sur le serveur, dans mon compte, je rajoute les clés publiques dans
le fichier authorized_keys
- re-démarrage du serveur ssh
Et quand je veux me connecter, il me re-demande mon mot de passe,
comme s'il ne reconnaissait aucune des trois clés publiques.
C'est bien le mot de passe qu'il vous demande et non pas la
« passphrase » ?
Oui, c'est bien le mot de passe du compte distant qu'il me demande.
Dans tous les cas, vérifiez les logs du serveur SSH, il vous indiquera
très certainement la raison du refus d'authentification par clé.
Je n'arrive pas à avoir plus d'infos dans les logs du serveur. J'ai
pourtant rajouté LogLevel DEBUG dans le fichier de config, mais ça ne
change rien. Tout ce que j'ai au moment de la connection c'est ça :
Mar 10 08:15:11 mdk_server sshd[3126]: Connection from
::ffff:193.50.21.121 port 42811
Mar 10 08:15:11 mdk_server sshd[3126]: Failed none for lassie from
::ffff:193.50.21.121 port 42811 ssh2
Mar 10 08:15:13 mdk_server sshd[3126]: Accepted password for lassie from
::ffff:193.50.21.121 port 42811 ssh2
Mar 10 08:15:17 mdk_server sshd[3134]: Connection closed by
::ffff:193.50.21.121
Mar 10 08:15:17 mdk_server sshd[3134]: Closing connection to
::ffff:193.50.21.121
On peut rencontrer ce problème en voulant par exemple utiliser une clé
DSA sur un serveur SSH utilisant le protocole version 1.
Mais plus généralement on rencontre ce problème quand les permissions
sur le répertoire ~/.ssh sont incorrectes.
$ chmod 0700 ~/.ssh ; chmod 0600 ~/.ssh/*
Voui, j'avais déjà regardé, mais ça ne change rien, il me demande
toujours mon password.
J'ai essayé de faire une chmod 755 aussi, mais pareil.
j'aurai voulu rajouter une authentification par clé et c'est là que ça coince : - génération les clés publiques et privées sous cygwin avec la commande ssh-keygen -t <type> (dsa, rsa, et rsa1)
Quel type avez-vous utilisé au final ?
Euh... les trois ! :-) J'ai mis les trois clés publiques dans le fichier authorized_keys (avec un cat key.pub >> authorized_keys)
Par défaut ces options sont à yes, il n'était donc pas forcément utile de les rajouter. Par contre, quelles sont les autres options qui sont renseignées dans ce fichier ?
Pour LogLevel, c'est moi qui ait essayé DEBUG, mais je ne vois rien de plus dans les traces après avoir redémarré le serveur
- sur le serveur, dans mon compte, je rajoute les clés publiques dans le fichier authorized_keys - re-démarrage du serveur ssh
Et quand je veux me connecter, il me re-demande mon mot de passe, comme s'il ne reconnaissait aucune des trois clés publiques.
C'est bien le mot de passe qu'il vous demande et non pas la « passphrase » ?
Oui, c'est bien le mot de passe du compte distant qu'il me demande.
Dans tous les cas, vérifiez les logs du serveur SSH, il vous indiquera très certainement la raison du refus d'authentification par clé.
Je n'arrive pas à avoir plus d'infos dans les logs du serveur. J'ai pourtant rajouté LogLevel DEBUG dans le fichier de config, mais ça ne change rien. Tout ce que j'ai au moment de la connection c'est ça :
Mar 10 08:15:11 mdk_server sshd[3126]: Connection from ::ffff:193.50.21.121 port 42811 Mar 10 08:15:11 mdk_server sshd[3126]: Failed none for lassie from ::ffff:193.50.21.121 port 42811 ssh2 Mar 10 08:15:13 mdk_server sshd[3126]: Accepted password for lassie from ::ffff:193.50.21.121 port 42811 ssh2 Mar 10 08:15:17 mdk_server sshd[3134]: Connection closed by ::ffff:193.50.21.121 Mar 10 08:15:17 mdk_server sshd[3134]: Closing connection to ::ffff:193.50.21.121
On peut rencontrer ce problème en voulant par exemple utiliser une clé DSA sur un serveur SSH utilisant le protocole version 1. Mais plus généralement on rencontre ce problème quand les permissions sur le répertoire ~/.ssh sont incorrectes.
$ chmod 0700 ~/.ssh ; chmod 0600 ~/.ssh/*
Voui, j'avais déjà regardé, mais ça ne change rien, il me demande toujours mon password. J'ai essayé de faire une chmod 755 aussi, mais pareil.
Merci pour les pistes en tout cas.
A+
Lassie
TiChou wrote:
Dans le message <news:, *TiChou* tapota sur f.c.o.l.configuration :
[...]
J'ai oublié de dire d'utiliser avec la commande ssh l'option -v, -vv ou -vvv pour rendre ssh bavard et rapporter tous les messages utiles pour débugger le problème.
Oui, j'avais essayé aussi : apparemment, il envoie bien la clé, mais on n'a pas la raison pour laquelle elle est refusée sur le serveur. Je ne comprends pas pourquoi je n'arrive pas à avoir plus de trace coté serveur... je vais y jeter un coup d'oeil.
Pour info, les traces coté client, ça donne ça :
debug1: Host 'mdk_server' is known and matches the RSA host key. debug1: Found key in /cygdrive/c/home/.ssh/known_hosts:1 debug2: bits set: 500/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: Enabling compression at level 6. debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /cygdrive/c/home/.ssh/id_rsa (0x100e9238) debug2: key: /cygdrive/c/home/.ssh/id_dsa (0x0) debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug3: start over, passed a different list publickey,password,keyboard-interact ive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /cygdrive/c/home/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug1: Trying private key: /cygdrive/c/home/.ssh/id_dsa debug1: read PEM private key done: type DSA debug3: sign_and_send_pubkey debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable meth debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: Next authentication method: password 's password: [ lassie]$ _
TiChou wrote:
Dans le message <news:bzium.20050309163414@florizarre.tichou.org>,
*TiChou* tapota sur f.c.o.l.configuration :
[...]
J'ai oublié de dire d'utiliser avec la commande ssh l'option -v, -vv ou
-vvv pour rendre ssh bavard et rapporter tous les messages utiles pour
débugger le problème.
Oui, j'avais essayé aussi : apparemment, il envoie bien la clé, mais on
n'a pas la raison pour laquelle elle est refusée sur le serveur. Je ne
comprends pas pourquoi je n'arrive pas à avoir plus de trace coté
serveur... je vais y jeter un coup d'oeil.
Pour info, les traces coté client, ça donne ça :
debug1: Host 'mdk_server' is known and matches the RSA host key.
debug1: Found key in /cygdrive/c/home/.ssh/known_hosts:1
debug2: bits set: 500/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: Enabling compression at level 6.
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /cygdrive/c/home/.ssh/id_rsa (0x100e9238)
debug2: key: /cygdrive/c/home/.ssh/id_dsa (0x0)
debug1: Authentications that can continue:
publickey,password,keyboard-interacti
ve
debug3: start over, passed a different list
publickey,password,keyboard-interact
ive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /cygdrive/c/home/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue:
publickey,password,keyboard-interacti
ve
debug1: Trying private key: /cygdrive/c/home/.ssh/id_dsa
debug1: read PEM private key done: type DSA
debug3: sign_and_send_pubkey
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue:
publickey,password,keyboard-interacti
ve
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue:
publickey,password,keyboard-interacti
ve
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable meth
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
lassie@mdk_server's password:
[lassie@mdk_server lassie]$ _
Dans le message <news:, *TiChou* tapota sur f.c.o.l.configuration :
[...]
J'ai oublié de dire d'utiliser avec la commande ssh l'option -v, -vv ou -vvv pour rendre ssh bavard et rapporter tous les messages utiles pour débugger le problème.
Oui, j'avais essayé aussi : apparemment, il envoie bien la clé, mais on n'a pas la raison pour laquelle elle est refusée sur le serveur. Je ne comprends pas pourquoi je n'arrive pas à avoir plus de trace coté serveur... je vais y jeter un coup d'oeil.
Pour info, les traces coté client, ça donne ça :
debug1: Host 'mdk_server' is known and matches the RSA host key. debug1: Found key in /cygdrive/c/home/.ssh/known_hosts:1 debug2: bits set: 500/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: Enabling compression at level 6. debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /cygdrive/c/home/.ssh/id_rsa (0x100e9238) debug2: key: /cygdrive/c/home/.ssh/id_dsa (0x0) debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug3: start over, passed a different list publickey,password,keyboard-interact ive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /cygdrive/c/home/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug1: Trying private key: /cygdrive/c/home/.ssh/id_dsa debug1: read PEM private key done: type DSA debug3: sign_and_send_pubkey debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable meth debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: Next authentication method: password 's password: [ lassie]$ _
Lassie
Philippe Delsol wrote:
Hello,
J'ai un petit problème sur une machine qui fait tourner un serveur sshd (Mandrake 10.1) : A partir d'un client sous Windows (et voui... snif... pas le choix...), j'ai installé Cygwin avec son package ssh qui va bien
Au cas où ... La solution client ssh Putty fonctionne très bien.
Je vais tester ça. Merci pour l'info.
Philippe Delsol wrote:
Hello,
J'ai un petit problème sur une machine qui fait tourner un serveur
sshd (Mandrake 10.1) :
A partir d'un client sous Windows (et voui... snif... pas le
choix...), j'ai installé Cygwin avec son package ssh qui va bien
Au cas où ... La solution client ssh Putty fonctionne très bien.
J'ai un petit problème sur une machine qui fait tourner un serveur sshd (Mandrake 10.1) : A partir d'un client sous Windows (et voui... snif... pas le choix...), j'ai installé Cygwin avec son package ssh qui va bien
Au cas où ... La solution client ssh Putty fonctionne très bien.
Je vais tester ça. Merci pour l'info.
TiChou
Dans le message <news:422ff4cb$0$9525$, *Lassie* tapota sur f.c.o.l.configuration :
Dans tous les cas, vérifiez les logs du serveur SSH, il vous indiquera très certainement la raison du refus d'authentification par clé.
Je n'arrive pas à avoir plus d'infos dans les logs du serveur. J'ai pourtant rajouté LogLevel DEBUG dans le fichier de config, mais ça ne change rien.
Alors stoppez le serveur ssh et lancez le dans une console en premier plan avec les options '-D' et '-ddd' :
$ /usr/sbin/sshd -D -ddd
Vous aurez ainsi dans votre console tous les messages de debug.
Tout ce que j'ai au moment de la connection c'est ça :
Mar 10 08:15:11 mdk_server sshd[3126]: Connection from ::ffff:193.50.21.121 port 42811 Mar 10 08:15:11 mdk_server sshd[3126]: Failed none for lassie from ::ffff:193.50.21.121 port 42811 ssh2
Ce message est curieux mais je ne serais l'interpréter.
Merci pour les pistes en tout cas.
Pas de quoi.
-- TiChou
Dans le message <news:422ff4cb$0$9525$636a15ce@news.free.fr>,
*Lassie* tapota sur f.c.o.l.configuration :
Dans tous les cas, vérifiez les logs du serveur SSH, il vous indiquera
très certainement la raison du refus d'authentification par clé.
Je n'arrive pas à avoir plus d'infos dans les logs du serveur. J'ai
pourtant rajouté LogLevel DEBUG dans le fichier de config, mais ça ne
change rien.
Alors stoppez le serveur ssh et lancez le dans une console en premier plan
avec les options '-D' et '-ddd' :
$ /usr/sbin/sshd -D -ddd
Vous aurez ainsi dans votre console tous les messages de debug.
Tout ce que j'ai au moment de la connection c'est ça :
Mar 10 08:15:11 mdk_server sshd[3126]: Connection from
::ffff:193.50.21.121 port 42811
Mar 10 08:15:11 mdk_server sshd[3126]: Failed none for lassie from
::ffff:193.50.21.121 port 42811 ssh2
Ce message est curieux mais je ne serais l'interpréter.
Dans le message <news:422ff4cb$0$9525$, *Lassie* tapota sur f.c.o.l.configuration :
Dans tous les cas, vérifiez les logs du serveur SSH, il vous indiquera très certainement la raison du refus d'authentification par clé.
Je n'arrive pas à avoir plus d'infos dans les logs du serveur. J'ai pourtant rajouté LogLevel DEBUG dans le fichier de config, mais ça ne change rien.
Alors stoppez le serveur ssh et lancez le dans une console en premier plan avec les options '-D' et '-ddd' :
$ /usr/sbin/sshd -D -ddd
Vous aurez ainsi dans votre console tous les messages de debug.
Tout ce que j'ai au moment de la connection c'est ça :
Mar 10 08:15:11 mdk_server sshd[3126]: Connection from ::ffff:193.50.21.121 port 42811 Mar 10 08:15:11 mdk_server sshd[3126]: Failed none for lassie from ::ffff:193.50.21.121 port 42811 ssh2
Ce message est curieux mais je ne serais l'interpréter.
Merci pour les pistes en tout cas.
Pas de quoi.
-- TiChou
TiChou
Dans le message <news:422ff70c$0$29929$, *Lassie* tapota sur f.c.o.l.configuration :
J'ai oublié de dire d'utiliser avec la commande ssh l'option -v, -vv ou -vvv pour rendre ssh bavard et rapporter tous les messages utiles pour débugger le problème.
Oui, j'avais essayé aussi : apparemment, il envoie bien la clé,
Oui, tout indique, dans les messages de debug, que les clés sont bien envoyées au serveur ssh mais qu'elles ne sont pas acceptées.
-- TiChou
Dans le message <news:422ff70c$0$29929$626a14ce@news.free.fr>,
*Lassie* tapota sur f.c.o.l.configuration :
J'ai oublié de dire d'utiliser avec la commande ssh l'option -v, -vv
ou -vvv pour rendre ssh bavard et rapporter tous les messages utiles pour
débugger le problème.
Oui, j'avais essayé aussi : apparemment, il envoie bien la clé,
Oui, tout indique, dans les messages de debug, que les clés sont bien
envoyées au serveur ssh mais qu'elles ne sont pas acceptées.
Dans le message <news:422ff70c$0$29929$, *Lassie* tapota sur f.c.o.l.configuration :
J'ai oublié de dire d'utiliser avec la commande ssh l'option -v, -vv ou -vvv pour rendre ssh bavard et rapporter tous les messages utiles pour débugger le problème.
Oui, j'avais essayé aussi : apparemment, il envoie bien la clé,
Oui, tout indique, dans les messages de debug, que les clés sont bien envoyées au serveur ssh mais qu'elles ne sont pas acceptées.
