[Résolu] ssh Authentication failed

Support Debian
#1

Bonjour à tous,

Récemment suite à la mise à jour de ma Debian Etch arm de mon NSLU2, je me suis retrouvé bloqué à l’extérieur de mon boitier. La dernière chose que j’ai pu voir sur mon terminal avant de ne plus pouvoir y accéder était la régénération des clés ssh suite à la détection des weak-keys présentes sur mon système lors de l’update.

Voici l’erreur :
$ ssh2 moi@192.168.2.20
warning: Authentication failed.
Disconnected; connection lost (Connection closed.).

Pour simplifier les choses, je n’ai que 2 manières d’accéder à mon NSLU2 qui n’a pas d’écran:

  • en ssh (c’est plutôt mal parti à priori)
  • en modifiant des fichiers sur ma clé usb sur laquelle est installé tout le système

J’ai l’impression que la solution ne doit pas être trop complexe, mais je n’ai pas réussi à réparer par moi-même. Est ce que vous verriez un moyen simple de remettre ça à plat?

Merci d’avance

#2

suite à la decouverte d’une faille de sécurité dans le paquet openssl de debian, les paquets utilisant le protocole comme ssh ont été lis à jour et les clés existante ont été révoqués. Il te faut donc régénéré tes clés ssh coté client ainsi que supprimer les anciennes coté serveur.

#3

C’est bizarre de que tu racontes (jhonjhon), j’ai quatre machines à la maison avec des partages de clés entre plusieurs utilisateurs sur ces quatre machines et le serveur sshd n’acceptant QUE les connexions par clé publiques sur chaque machine.

Après la mise à jour de sécurité qui m’a révoqué les certificats et les clés faibles, je me suis connecté en utilisant les mot de passe des utilisateurs. Il semble que la mise à jour a modifié la configuration de sshd… afin que je puisse me connecter malgré tout. Curieux que ce ne soit pas le cas chez toi! Et embêtant vu ta configuration.

Si tu peux modifier le fichier /etc/ssh/sshd_config en retirant la clé USB contenant le système, tu devrais t’en sortir avec ça:

# Change to no to disable tunnelled clear text passwords PasswordAuthentication yes
Que tu changes en no après avoir fait l’échange de clés publiques!

#4

Tout d’abord merci de vos réponses rapides !

Oui en fait je trouve aussi que c’est assez curieux. Je pense qu’il y a du avoir un pb lors de la regénération des clés. Quel pb exactement, je compte bien regarder dès que j’aurai retrouvé l’accès!

J’ai pas eu le temps de retoucher le sshd_config et en effet ça me parait une bonne idée. Heureusement que me méfiant énormément des modifs automatiques, j’ai backupé mes fichiers de conf…

Donc en somme,

  1. je change le sshd_config
  2. je régénère une paire de clés
  3. je remets le sshd_config d’origine
  4. je relance le service et me log
  5. ça marche ?

Je ne peux mettre la main sur mon serveur que ce soir, je vous tiendrai au courant dès lors.

#5

[quote=“Johnjohn”]Tout d’abord merci de vos réponses rapides !

Oui en fait je trouve aussi que c’est assez curieux. Je pense qu’il y a du avoir un pb lors de la regénération des clés. Quel pb exactement, je compte bien regarder dès que j’aurai retrouvé l’accès!

J’ai pas eu le temps de retoucher le sshd_config et en effet ça me parait une bonne idée. Heureusement que me méfiant énormément des modifs automatiques, j’ai backupé mes fichiers de conf…

Donc en somme,

  1. je change le sshd_config
  2. je régénère une paire de clés
  3. je remets le sshd_config d’origine
  4. je relance le service et me log
  5. ça marche ?

Je ne peux mettre la main sur mon serveur que ce soir, je vous tiendrai au courant dès lors.[/quote]
Salut, elle est où ta clé USB dans ta manip?
0) Clé USB débranchée du NSLU2 branchée sur ton poste de travail

  1. Modifs du sshd_config
  2. Branchement de la clé USB puis boot
  3. Authentification par ssh avec le mot de passe de l’utilisateur; génération de nouvelles clés (là où elles sont “faibles”) puis échange des clés publiques
  4. sshd_config origine
  5. /etc/init.d/ssh reload
  6. ça devrait marcher, pas la peine de te reconnecter, la connexion est conservée lors du reload. Par contre ça vaut le coup d’essayer à nouveau de te connecter depuis un autre xterm ou tty pour voir si c’est OK au niveau des clés… Avant de devoir recommencer toute la procédure!
#6

Bon me voila rentré chez moi.
Pas de mieux en ayant modifié le sshd_config. (j’étais allé au plus vite dans mes étapes mais je pensais la même chose que toi ziouplaboum :slightly_smiling: )
J’ai fait un debug de ssh pour essayer de comprendre
Je trouve qu’il s’arrête très vite vous en pensez quoi ?

$ ssh jo@192.168.2.20 -p9000 -v debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to 192.168.2.20 [192.168.2.20] port 9000. debug1: Connection established. debug1: identity file /home/john/.ssh/identity type -1 debug1: identity file /home/john/.ssh/id_rsa type 1 debug1: identity file /home/john/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2 Debian-9etch2 debug1: match: OpenSSH_4.3p2 Debian-9etch2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2 debug1: SSH2_MSG_KEXINIT sent Read from socket failed: Connection reset by peer

#7

Que dit le log auth.log sur le serveur 192.168.2.20?

#8

Bonjour à toi ripat et merci de m’aider

Voila ce qu’on trouve coté serveur (de nombreuses fois à chaque tentative en fait)

May 28 19:07:39 PARTAGE sshd[1942]: error: Host key c7:18:8f:7f:92:a2:77:84:13:8f:08:67:54:7e:fb:95 blacklisted (see ssh-vulnkey(1))
May 28 19:07:39 PARTAGE sshd[1942]: error: Host key ee:e6:ea:ce:c8:9b:c1:fa:15:9e:9f:28:82:f6:70:2a blacklisted (see ssh-vulnkey(1))
#9

[quote=“Johnjohn”]

c7:18:8f:7f:92:a2:77:84:13:8f:08:67:54:7e:fb:95 blacklisted (see ssh-vulnkey(1)) [/quote]
Ça m’a l’air clair. Ta clef est une de celle générée par un ssh-keygen moribond en manque d’entropie; en gros elle fait partie d’une liste étriquée de clefs vulnérables, voir les nombreux messages dans ce forum et ailleurs…
Sur ta machine cliente; déplace ta clef ailleurs, ou supprimes là (dans le doute déplace la!), retente de te connecter, ssh ne trouvant pas de clef publique va te demander une authentification par mot de passe. Tu as déplacé/supprimé les clefs sur ton serveur?

#10

Bon soit je suis fatigué soit je n’y comprends décidement plus rien…

Sur mon client j’ai regénéré des clés toutes neuves.
Mais toujours la même erreur en me connectant, et il ne me propose pas de passer par le password…

J’ai déplacé mes clés côté serveur mais même erreur… Je ne pourrais pas regénérer des clés pour le serveur histoire qu’elles soient propres ?

#11

Bon problème résolu mais je ne suis pas sûr de l’avoir fait de la plus belle manière !

J’ai recréé des clés serveurs sur mon pc client que j’ai tranférées sur mon serveur.
Ensuite je me suis logué en ssh et ca a fonctionné !

En fait je trouvais bizarre qu’il ne m’affiche pas çà The authenticity of host 'xx.xx.xx.xx (xx.xx.xx.xx)' can't be established. depuis le début de cette histoire. Avec toutes les manip de clés que j’ai faites il aurait bien du s’affoler c’est donc que quelquechose n’allait pas.

Et comme je le pressentait, il s’était bien passé quelque chose de pas net pendant la mise à jour qui a lancé ce problème.

Un petit apt-get update m’a donné
[…]
E: dpkg was interrupted, you must manually run ‘dpkg --configure -a’ to correct the problem.
:~# dpkg --configure -a
Setting up openssh-server (4.3p2-9etch2) …

Bref, merci à tous de votre aide.
Je laisse le topic ouvert si jamais j’ai encore des soucis

#12

:slightly_smiling:

#13

Bon voila quelques jours que çà fonctionne impeccable.
Merci à tous de votre aide

Ps: je marque le sujet comme résolu