web-dev-qa-db-fra.com

mysql workbench n'a pas réussi à se connecter au serveur via le tunnel ssh après la mise à niveau du serveur vers Ubuntu 16.04

J'ai eu une connexion active dans MySQL Workbench à mon tunnel Ubuntu 14.04 sur ssh au cours des deux dernières années sans aucun problème. Mais après la mise à niveau vers la nouvelle version 16.04 d’Ubuntu, je continue à recevoir l’erreur suivante:

13:41:56 [INF][     SSH tunnel]: Starting tunnel
13:41:56 [INF][     SSH tunnel]: Existing SSH tunnel not found, opening new one
13:42:03 [INF][     SSH tunnel]: Opening SSH tunnel to xxx.xxx.xxx.xxx:22
13:42:03 [INF][     SSH tunnel]: TunnelManager.wait_connection authentication error: Authentication error, unhandled exception caught in tunnel manager, please refer to logs for details
13:42:03 [ERR][     SSH tunnel]: Authentication error opening SSH tunnel: Authentication error, unhandled exception caught in tunnel manager, please refer to logs for details

Notes qui peuvent être utiles:

  1. Je peux me connecter via le tunnel SSH de HeidiSQL.
  2. Je n'arrive pas à établir la connexion avec Navicat et je continue à obtenir SSH:expected key exchange group packet from server.

J'ai beaucoup lu pour résoudre ce problème, certaines suggestions sont ici:

  • générer une nouvelle clé ssh sur le serveur,
  • ajoutez KexAlgorithms à la fin de sshd_config,
  • upgrade paramiko paquet de workbench Python.

J'apprécie toute aide que vous fournirez.

16.04sshmysqltunnelmysql-workbench
1
Hamid

Après avoir vérifié le problème et essayé de reproduire les problèmes sur d’autres ordinateurs et ceux qui ont été connectés avec succès. J'ai découvert que le problème est causé par la mise en cache de ssh Host connu.

Je supprime le dossier sous le user\application data\roaming\mysql\workbench\ssh\ mais le problème demeure.

Pour le dernier essai, je désinstalle MySql Workbench et supprime le dossier de configuration mentionné précédemment, puis installe la version récemment téléchargée de MySql Workbench. Heureusement, tout fonctionne bien.

0
Hamid

Vous avez trouvé la réponse ici: https://stackoverflow.com/a/26584947/5201045

Veuillez utiliser le niveau DEBUG3. Ensuite, vous verrez la liste des algorithmes d’échange de clés configurés sur votre serveur ainsi que la liste prise en charge par votre client.

Ajoutez ensuite la ligne suivante à votre/etc/ssh/sshd_config:

KexAlgorithms <here comma-separated list of Kex Algorithms configured on your server>,<here one of the Kex Algorithms supported by your client>

Par exemple, OpenSSH 6.7 utilise par défaut les algorithmes suivants: curve25519-sha256 @ libssh.org, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffd-hellman-group-exchange-sha256, Diffie-Hellman-Group14-Sha1.

Si votre client ne prend en charge que diffie-hellman-group1-sha1, votre/etc/ssh/sshd_config doit contenir

KexAlgorithms [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

Ce n'est pas grave - OpenSSH v.6.7 prend également en charge diffie-hellman-group1-sha1, mais il est désactivé par défaut. Vous devez autoriser sshd à utiliser cet algorithme d'échange de clés en plaçant la ligne KexAlgorithms dans votre configuration sshd.

Crédits à Nikolay

Add-on: Redémarrez votre service ssh après

#/etc/init.d/ssh restart
0
Ray

J'ai résolu ce problème en rétrogradant le paquet python-crypto dans Ubuntu 16.04. Annulez la version 2.6.1-6ubuntu0.16.04.2 à 2.6.1-6build1 en utilisant la commande ci-dessous.

Sudo apt-get install  python-crypto=2.6.1-6build1

ref: https://forums.mysql.com/read.php?152,655178,655194#msg-655194

0
Vaibhav Panmand