Essayer d'utiliser MySQL Workbench avec TCP / IP sur SSH - échec de la connexion

Je ne parviens pas à me connecter via TCP / IP sur SSH dans MySQL Workbench à partir d'un PC. Que se passe-t-il?

J'ai créé une base de données MySQL 5.1 sur un serveur Ubuntu, mysql.myhost.com . Je peux y accéder localement. MySQL Workbench (PC) offre l’établissement d’une connexion via TCP sur ssh. Il fonctionne sur le port 3306 sur le serveur distant où mysql en ligne de commande fonctionne correctement.

J'ai utilisé les détails de la session suivants:

• Méthode de connexion: TCP / IP sur SSH.
• Nom d'hôte SSH: mysql.myhost.com : 3306
• Nom d'utilisateur SSH: mon login linux
• Fichier de clé publique SSH: mon fichier de clé publique locale
• Nom d'hôte MySQL: 127.0.0.1 MySQL
• Port du serveur: 3306
• Nom d'utilisateur: root

Je reçois un message d'erreur lorsque j'essaie de me connecter: "Échec de la connexion à MySQL via 127.0.0.1:3306 via le tunnel SSH à l'adresse mysql.myhost.com avec l'utilisateur root"

"Impossible de se connecter au serveur MySQL sur '127.0.0.1' (10061)"

Autre test: j'ai configuré un tunnel SSH avec le port 3306 sous Putty et je peux me connecter correctement à l'aide de MySQL Workbench via ce tunnel, qui transmet les connexions de mon 3306 local au serveur distant, comme décrit ci-dessus. Mais je ne parviens pas à utiliser "TCP / IP sur SSH" dans Workbench.

Question secondaire: lorsque Workbench demande "Chemin d'accès au fichier de clé publique SSH", n'a-t-il pas vraiment besoin de mon fichier de clé privée?

Je suis tombé sur cette question quand j'ai moi-même rencontré cette erreur. Je pouvais enfin comprendre la configuration.

1. Je n'ai touché à rien dans /etc/mysql/my.cnf qui a déjà bind_address = 127.0.0.1. Donc, seul localhost peut se connecter.
2. J'utilise le serveur OpenSSH. Donc, dans son fichier de configuration / etc / ssh / sshd_config, je suis passé de no à yes, le param responsable du transfert de TCP, donc AllowTcpForwarding oui .

3. Enfin, les éléments suivants sont entrés dans MySQL WorkBench.

   • Nom d'hôte SSH: 192.168.0.8:22 (mon serveur SSH écoute le port 22)
   • Nom d'utilisateur SSH: sshuser
   • Fichier de clé SSH: * C: \ Utilisateurs \ windowsuser \ .ssh \ id_rsa * (doit être une clé privée, même si elle est publique)
   • Nom d'hôte MySQL: 127.0.0.1 (cela ne devrait pas être changé, car le serveur MySQL est lié par défaut à localhost uniquement, ce que je n'ai pas changé)
   • Port du serveur MySQL: 3306 (également par défaut)
   • Nom d'utilisateur: root

La seule chose qui vous reste à faire est de configurer correctement votre serveur SSH pour qu’il utilise des clés plutôt que des mots de passe. J'espère que cela aidera quelqu'un.

Je pense que l'approche TCP / IP sur SSH fonctionne en établissant une connexion SSH "normale" sous-jacente à la connexion MySQL (de la même manière que vous utiliseriez un tunnel -Lavec le client de ligne de commande OpenSSH).

Par conséquent, vous devez spécifier une connexion à un serveur SSH sur le serveur via lequel vous établissez le tunnel. Ici, vous semblez utiliser mysql.myhost.com:3306, ce qui impliquerait que vous utilisez ce serveur SSH (pas MySQL) sur le port 3306.

Il est possible de lier un serveur MySQL sur 127.0.0.1:3306 et un serveur SSH sur votre adresse IP externe pour mysql.myhost.comle port 3306, mais c'est très peu probable. Je suppose que votre serveur SSH est à l’écoute sur le port 22 (par défaut).

Vous devriez probablement utiliser mysql.myhost.com:22. (Vérifiez que vous pouvez vous y connecter via un client SSH normal tel que Putty.)

Vous devrez peut-être vérifier les utilisateurs dans la table mysql.user.

Exécutez cette requête:

SELECT user,host FROM mysql.user;

Vous devriez voir quelque chose comme ça:

mysql> SELECT user,host,password FROM mysql.user;
+------------------+-------------+-------------------------------------------+
| user             | host        | password                                  |
+------------------+-------------+-------------------------------------------+
| root             | localhost   | *7A670E02260CDEEFF062DD08F3A6F6DA079998CB |
| ping             | %           | *124E1DB56CC8D6E2FEE8315BB2544BF04B980DB6 |
| admin            | 10.67.135.% | 1a6858054a41fede                          |
| icorbin          | 10.67.135.% | 366ed93a7396650e                          |
+------------------+-------------+-------------------------------------------+
4 rows in set (0.00 sec)

S'il vous plaît noter que

• root @ localhost peut uniquement se connecter à partir de localhost.
• ping @ '%' peut se connecter via TCP / IP
• admin@10.67.135.% pouvez vous connecter via TCP / IP à partir de ce netblock uniquement
• icorbin@10.67.135.% pouvez vous connecter via TCP / IP à partir de ce netblock uniquement

Si vous souhaitez que root se connecte via TCP / IP, vous devez spécifier l'adresse IP ou netblock pour un utilisateur root.

Quelque chose comme ça:

GRANT ALL PRIVILEGES ON *.* TO root@'%' IDENTIFIED BY 'whateverpassword';

ou si le mot de passe root est le même pour root @ localhost alors

GRANT ALL PRIVILEGES ON *.* TO root@'%' IDENTIFIED BY PASSWORD '*7A670E02260CDEEFF062DD08F3A6F6DA079998CB ';

CAVEAT: root @ '%' n'est normalement pas recommandé. Essayez peut-être root@'10.% 'ou n’importe quel autre netblock pour root.

Essaie !!!

Vous utilisez peut-être une ancienne version de MySQL Workbench et devez effectuer une mise à jour. Il s'agit d'un bogue dans la version 6.0.8, qui est actuellement la version dans les référentiels Ubuntu. La mise à jour vers la version 6.3.6 a corrigé cela pour moi.

Téléchargements ici: http://dev.mysql.com/downloads/workbench/#downloads

Une chose qui n’est mentionnée dans aucune autre réponse est l’importance du format OpenSSH pour la clé, comme indiqué dans le SO ( https://stackoverflow.com/questions/34504232/mysql-workbench-failing-toconnect-via- ssh-due-to-key / 38108623 # 38108623 ).

Malgré la réponse, j’ai pu utiliser une clé protégée par mot de passe avec MySQL Workbench 6.3.7 (64 bits, Windows 10).

Mon problème était dû au fait que j'essayais d'utiliser une ed25519clé SSH. J'ai remarqué cette erreur sur le serveur SSH dans auth.log:

sshd[25251]: Connection closed by 192.168.x.x [preauth]

Une fois que je suis passé à l’utilisation d’une clé RSA, tout a fonctionné comme prévu.

Vous essayez de vous connecter au serveur via ssh mais en utilisant le port mysql. Le port que vous voulez est celui que votre serveur ssh écoute, généralement 22, puis localhost et 3306 pour le nom d’hôte et le port mysql.

J'ai rencontré le même problème. J'ai vérifié et essayé de définir AllowTcpForwarding sur Oui, mais il manquait dans mon sshd_config, donc aucune aide. assurez-vous que le nom d'hôte ssh n'est PAS identique au nom d'hôte mysql (utilisez localhost).

Dans Workbench, choisissez + pour ajouter une nouvelle connexion et définissez les éléments suivants:

• méthode de connexion: TCP / IP standard sur SSH
• Nom d'hôte SSH: 192.168.0.50:22 (placez l'adresse IP et le port du serveur SSH distant (facultatif))
• Nom d'utilisateur SSH: sshuser
• Vous pouvez définir un mot de passe ou ajouter à l'invite
• Nom d'hôte MYSQL: localhost ou 127.0.0.1
• Port du serveur MYSQL: 3306
• Vous pouvez définir un mot de passe ou ajouter à l'invite

Tester la connexion. Il devrait être réussi, puis cliquez sur OK.Viola!

Parfois, les clés créées par PuTTY ne fonctionnent pas. Utilisez ssh-keygen sur le système Linux pour créer une paire de clés. Copiez le contenu du nouvel id_rsa dans un fichier texte sous Windows. Assurez-vous d’ajouter le contenu de id_rsa.pub à allowed_keys sur la machine Linux. Toutes les autres valeurs par défaut dans Workbench sont correctes, notamment 127.0.0.1 pour le nom d’hôte MySQL. Bien entendu, il doit s'agir d'un protocole TCP / IP standard sur SSH.

J'ai eu la même erreur. Le problème est "un peu" le délai d'attente. J'ai lancé même la valeur jusqu'à 120 secondes qui n'a pas aidé.

Dans mon cas, je pourrais le résoudre en faisant un nslookup myserver.com et en utilisant l'adresse IP à la place du nom d'hôte. Mon hypothèse est un problème en essayant de se connecter d'IPv4 à IPv6.

Je viens d'avoir ce même problème sur une machine Ubuntu qui se connecte à un serveur exécutant MySQL version 5.5.29 et MySQL Workbench 5.2.40. Le serveur SSH nécessite l'utilisation d'une clé ssh.

Je ne pouvais pas me connecter au serveur MySQL en utilisant l'utilisateur root, mais je devais créer un utilisateur non root distinct à utiliser pour la connexion. Après cela, j'ai pu me connecter très bien.

J'espère que cela t'aides.

OK, je sais que c’est une vieille question, mais j’ai tiré mes cheveux dessus pendant des heures. J'ai vérifié tout ce qui avait été mentionné par Bruno et Eye et tout semblait bien aller. Ensuite, j'ai réalisé que c'était vraiment une affaire de clé privée / publique. J'ai donc lancé Pageant et ajouté ma clé privée, afin de créer une clé publique que MySQL Workbench pourrait lire et le tour est joué, connecté! (C’était en fait une sorte d’acclimatation lorsque MySQL Workbench a commencé à fonctionner, mais de manière heureuse.)

TLDR: Utilisez Pageant pour générer une clé publique à partir de votre clé privée.

Seulement ce que j'ai trouvé ... souvent, je crée des utilisateurs sur un serveur SSH sans shell (tel que / sbin / nologin) pour les empêcher de pouvoir se connecter à un serveur et de créer des fichiers, etc. ... (pour les systèmes de production le fais sur des pare-feu).

Dans un environnement Linux normal, vous pouvez toujours transférer les ports suivants:

ssh -Nf -L 3306:%mysql_ip%:%mysql_port% %ssh_host%

et ensuite vous y connecter depuis le poste de travail local en tant que:

mysql -h localhost:3306 -u %mysql_user% -p

Mais workbench donne une erreur disant qu’il ne peut pas se connecter à MySQL ... Si vous voulez changer le shell pour que cet utilisateur puisse, disons, / bin / bash, tout fonctionnera correctement par la suite.

Aucune idée pourquoi Workbench exige un shell local sur le serveur SSH distant.

Créez simplement une nouvelle clé RSA au format correct pour mysql workbench.

Par exemple:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"