Bonjour à tous,
J'ai installé openssh sur de nombreuses machines mais j'ai un problème avec une.
Il m'est impossible de me conneter en ssh sur une autre machine avec un user différent de root.
Voilà ce que j'obtient :
$ ssh sersys2
Host key verification failed.
Si je mets las clé du host dans le known_hosts j'obtiens :
$ ssh sersys2
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password,keyboard-interactive).
Alors que je n'ai pas eu le temps de lui donner le moindre mot de passe.
Et ceci quelque soit le serveur sur lequel je veux me connecter et quelque soit le compte (à part root où cela fonctionne.)
Je suis déséspéré, si quelqu'un avait une idée ou une piste où chercher ce serait sympa car à part la resinstalle du serveur je vois plus là.
Pour info il s'agit d'un RS/6000 AIX5.2 avec openssh 3.8.1.0
La log avec -v-v-v-v (pas super utile mais bon :):
$ ssh -v -v -v -v -v sersys2
OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.6l 04 Nov 2003
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to sersys2 [53.120.29.52] port 22.
debug1: Connection established.
debug1: identity file /home/sdidie/.ssh/id_rsa type -1
debug1: identity file /home/sdidie/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.7p1
debug1: match: OpenSSH_3.7p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-dss,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
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
debug2: dh_gen_key: priv key bits set: 142/256
debug2: bits set: 505/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/sdidie/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /home/sdidie/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host 'sersys2' is known and matches the DSA host key.
debug1: Found key in /home/sdidie/.ssh/known_hosts:1
debug2: bits set: 521/1024
debug1: ssh_dss_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
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: /home/sdidie/.ssh/id_rsa (0)
debug2: key: /home/sdidie/.ssh/id_dsa (0)
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred hostbased,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: Trying private key: /home/sdidie/.ssh/id_rsa
debug3: no such identity: /home/sdidie/.ssh/id_rsa
debug1: Trying private key: /home/sdidie/.ssh/id_dsa
debug3: no such identity: /home/sdidie/.ssh/id_dsa
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-interactive
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
debug3: packet_send2: adding 64 (len 51 padlen 13 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.
debug3: packet_send2: adding 64 (len 51 padlen 13 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.
debug3: packet_send2: adding 64 (len 51 padlen 13 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,password,keyboard-interactive).
# pb de config ?
Posté par patatorz . Évalué à 1.
c'est certainement un pb de config;
soit ta conf cliente n'est pas compatible avec celle du serveur, soit l'inverse.
Le message "Host key verification failed" me laisse penser que tu devrais peut-etre desactiver l'option de verification des hosts.
Envoies donc la conf cliente de ta machine et la conf du serveur (sshd_config), ca sera plus simple pour t'aider, sinon c'est difficile de parler "dans le vide" ...
# Re : Problème openSSH
Posté par tontonflingueur . Évalué à 1.
- même si c'est un outil fantastique dont je ne pourrais plus guère me passer (ah les tunnels, l'authentification automatique par clefs !!!).
Notamment les
> debug1: Authentications that can continue:publickey,password,keyboard-interactive
alors qu'il a cessé la tentative d'authentification publickey depuis longtemps.... D'ailleurs qui dit ça ? le client ? le serveur ? on sait pas ! La dernière fois où j'ai voulu configurer openssh 3.8 avec kerberos, ça s'est terminé à coup de printf.
Là j'ai l'impression que ta config client /usr/local/etc/ssh_config n'autorise pas l'authentification par mot de passe ce qui explique que l'on ne te donne pas la chance de le rentrer. Il faudrait que tu édites ce fichier, ou, si tu n'est pas root - ce qui a des chances d'être le cas vu l'OS et la bécane - $HOME/.ssh/ssh_config pour mettre :
> Host *
> PasswordAuthentication yes
je pense que c'est le cas, parce que :
1) tu as l'air d'avoir un fichier "non standard", notamment avec
StrictHostKeyChecking à "yes", et non "ask" comme c'est le cas par défaut (sinon, tu n'aurais pas les "Host Key verification failed").
2) parmi tous les serveurs, ce serait le diable si tu n'en n'avait pas un qui autorise l'authentification par mot de passe !!!
Voilà mais ce ne sont que des impressions : tiens nous au courant.
# Si tu lis l'anglais
Posté par Nico . Évalué à 1.
- SSH Host Key Protection http://www.securityfocus.com/infocus/1806(...)
Il y a encore deux bons articles sur le sujet :
- SSH User Identities : http://www.securityfocus.com/infocus/1810(...)
- SSH and ssh-agent : http://www.securityfocus.com/infocus/1812(...)
[^] # Re: Si tu lis l'anglais
Posté par flechter . Évalué à 1.
Mais par contre cela n'a pas résolu mon problème :)
Je crois avoir pratiquement tout essayé.
J'ai desinstallé ssh (et tous les fichiers residuel) rebooté et reinstallé ssh et paf toujours le même problème.
J'ai testé à peut près toutes les configurations possible de mon sshd_config rien ne fonctionne.
Il me reste plus que la resintallation de l'OS ce qui ne m'arrange franchement pas car j'ai nagios, mon serveur NIM et le framework TIVOLI d'installé dessus :(
En fait j'avais fait des test pour configurer un serveur LDAP pour l'autenfication sur ce serveur (ainsi qu'un serveur NIS) et je me demande si ça ne pose pas un problème quelque part ...
C'est tout de mêm bisare car j'ai bien du installé SSH sur 20 serveurs seul celui là pose problème, et uniquement sur des users autres que root ce qui est encore plus étrange.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.