"Lost connection to MySQL..." avec HeidiSQL (semi-résolu)

Buddy 2017-01-11 12:44:38 UTC #9

Non, ils ne sont pas concernés.

Il faudrait voir concrètement ce qui pose problème ...
Le tunnel est correctement fait ?
Les ports sont bien forwardés ?

GlobuleVert 2017-01-11 12:53:39 UTC #10

Normalement il est correct puisqu'il fonctionnait juste avant mon départ en vacances. Je ne me souviens pas avoir changé la config...

Qu'entends-tu par "ports forwardés" ? J'utilise le port 22 pour le tunnel et le 3306 pour la BDD.

Buddy 2017-01-11 12:57:25 UTC #11

C'est possible qu'OVH ait légèrement modifié sa config et qu'il faille que tu adaptes la tienne.

Il faudrait vérifier que lorsque tu tentes de te connecter à ta base de données via heidiSQL, la requête passe bien via le tunnel et le mutualisé.

Il faudrait également vérifier que la résolution du "domaine du serveur BDD" se fait bien aussi.

GlobuleVert 2017-01-11 13:08:19 UTC #12

Dans le log d'OVH relatif à SSH, la connexion a bien l'air de se faire :

[2017 Jan 11 12:48:20] Accepted keyboard-interactive/pam for [mon nom d'utilisateur] from 82.xxxxxxxxxx port 51430 ssh2
[2017 Jan 11 12:48:58] Accepted keyboard-interactive/pam for [mon nom d'utilisateur] from 82.xxxxxxxxxx port 51436 ssh2
[2017 Jan 11 12:48:43] Accepted keyboard-interactive/pam for [mon nom d'utilisateur] from 82.xxxxxxxxxx port 51433 ssh2
[2017 Jan 11 13:05:53] pam_unix(sshd:session): session closed for user [mon nom d'utilisateur]
[2017 Jan 11 13:06:41] Accepted keyboard-interactive/pam for [mon nom d'utilisateur] from 82.xxxxxxxxxx port 52127 ssh2
[2017 Jan 11 12:53:59] Accepted keyboard-interactive/pam for [mon nom d'utilisateur] from 82.xxxxxxxxxx port 51778 ssh2
[2017 Jan 11 13:05:04] Accepted keyboard-interactive/pam for [mon nom d'utilisateur] from 82.xxxxxxxxxx port 52110 ssh2
[2017 Jan 11 13:05:34] pam_unix(sshd:session): session closed for user [mon nom d'utilisateur]
[2017 Jan 11 13:06:19] pam_unix(sshd:session): session closed for user [mon nom d'utilisateur]
[2017 Jan 11 13:10:58] pam_unix(sshd:session): session closed for user [mon nom d'utilisateur]
[2017 Jan 11 13:22:07] pam_unix(sshd:session): session closed for user [mon nom d'utilisateur]

L'identifiant de base de données que j'utilise est "mysql5-23.perso". Je viens d'essayer avec les nouveaux noms "xxxxx.mysql.db" mais sans résultat...

SebastienF 2017-01-11 13:29:51 UTC #13

Bonjour,

même problème ici (gestion avec Sequel Pro) et en quête d'une solution.

Je passe aussi via tunnel SSH.
Je ne rencontre pas le problème sur les serveur SQL Privé cependant.

micheloupatrick 2017-01-12 15:33:49 UTC #14

Idem pour moi avec Sequel Pro et MySQL Workbench, alors que tout fonctionnait parfaitement depuis des années (depuis 2011 je pense).
Cela signifie-t-il qu'il faille passer à un SQL Start ou privé pour conserver la fonctionnalité (ma connexion par tunnel SSH à un SQL privé sur un autre serveur OVH marche toujours) ?
C'est moyen comme pratique commerciale...

SebastienF 2017-01-12 15:59:16 UTC #15

un tech OVH pourrais intervenir et noux expliquer ?
Quelle galère de travailler avec PhpMyAdmin

Ludo.H 2017-01-13 16:55:41 UTC #16

Bonjour,

Le forwarding fonctionne toujours bien, il n'est pas désactivé en conf. :

depuis un poste personnel:

$ ssh mutu -L 3306:<ip du mysql>:3306
 <id>@ssh1.cluster017.ha.ovh.net ~ $

depuis un autre terminal du poste perso :

$ nc localhost 3306
5.5.52-0+deb7u1-log�XJ)py2)w>l��!�'zUx|)SE?LAAmysql_native_password%

Tout fonctionne.

Toute fois, les serveurs SSH n'ont pas vocation à servir de forwarder de port.
Ce service peut couper à tout moment, il n'est pas garantit.

Cdt,

GlobuleVert 2017-01-13 17:10:18 UTC #17

Bonsoir @Ludo.H , avez-vous des pistes pour la question initiale ?

GlobuleVert 2017-01-14 22:58:19 UTC #18

Un autre élément : le panneau d'administration OVH me "recommande de passer à l'offre Pro"... alors que je suis déjà en Pro. Peut-être que cette mauvaise détection de l'offre rend le SSH indisponible ?

(Pour être précis, le panneau dit que je suis en offre "Pro 2010".)

GlobuleVert 2017-01-17 18:19:34 UTC #19

Bonjour, de retour avec une bonne nouvelle : j'ai eu la réponse du support.

Et donc, la mauvaise nouvelle : c'est une mise à jour d'OVH qui a volontairement désactivé la possibilité de se connecter aux bases de données via SSH, les connexions ne peuvent venir que de l'hébergement lui-même (@janus57, tu avais totalement raison). Il n'y a donc pas de retour de HeidiSQL (ou autre logiciel) à espérer...

micheloupatrick 2017-01-17 19:39:57 UTC #20

OK, merci en tout cas d'avoir partagé la réponse.
Mais comme je tiens à cette fonctionnalité, t'ont-il dit si cela est possible avec un Start SQL ? Je serais prêt à payer un peu pour ne pas devoir passer par phpMyAdmin.

SebastienF 2017-01-18 14:18:37 UTC #22

Génial.....

Pour info cela fonctionne toujours avec un SQL Privé.

PhilippeC4 2017-01-18 14:36:26 UTC #23

Bonjour. J'ai exactement le même problème sur un hebergement mutualisé.
Voilà comment je l'ai résolu.

Avant toute chose, il faut un utilisateur ayant les droits SSH, donc un hébergement "pro" minimum.
Pour info et depuis 5 ans, l'utilisateur FTP pouvait créer un tunnel SSH (même en hébergement "perso"), mais je pense qu'il s'agissait d'un utilisateur SSH par défaut auquel personne n'aurait jamais du avoir accès ainsi. Bref ...

Ensuite, le tunnel SSH doit être créé avec l'adresse IP du serveur MySQL : il ne faut donc pas employer le nom du serveur (genre "mysqlXX-XXX.perso" ou "maBase.mysql.db"), mais bien une adresse chiffrée type 123.456.789.12
Pour obtenir l'adresse IP correspondant à votre nom de serveur MySQL, connectez-vous dans un terminal en SSH, puis effectuer un ping :

ssh monUtilisateurSSH@ftp.monDomaine.com
ping maBase.mysql.db

Enfin, utilisez cette adresse IP dans votre logiciel préféré de gestion MySQL et cela fonctionnera comme avant.
Testé avec Sequel Pro : je n'ai eu qu'à remplacer "maBase.mysql.db" par l'adresse IP dans le champ "MySQL Host". Cela devrait être aussi imple avec MySQL Workbench, Querious, ...

Au cas où vous auriez le message suivant quand vous faites un ping : "ping: icmp open socket: Operation not permitted"
C'est un problème d'environement d'execution : il faut que vous basculiez en mode "stable" (et non pas "legacy"). Plus d'info sur ce post d'OVH : https://docs.ovh.com/fr/fr/web/hosting/modifier-lenvironnement-dexecution-de-mon-hebergement-web/
Une fois l'adresse IP trouvée, vous pouvez revenir à la configuration initiale.

J'espère que cela aidera ceux qui sont confronté à ce problème. Je me suis arraché quelques cheveux, car bien sûr, impossible de travailler avec PhpMyAdmin ...
En esperant que les admins ne vérouillent pas encore plus l'usage d'un hébergement "pro". Du moins sans prévenir.
Bon courage.

Buddy 2017-01-18 14:51:00 UTC #24

Autant rester définitivement sur l'environnement stable qui apporte un environnement à jour.

Ludo.H 2017-01-18 14:57:09 UTC #25

Bonjour,

Pour le moment le forwarding est toujours fonctionnel via l'IP.
Cependant sous peu, et pour des raisons évidentes de sécurité, nous allons coupé tout forwarding.

Raisons :

Le rebond peut servir pour des attaques sur nos ip internes
Le rebond peut servir pour des attaques sur des ip externes
Nous avons trouver des remote forwarding avec des port binder sur nos SSH et allant vers l'exterieur, nous ne voulons pas de ce type de comportement.

Cdt,

PhilippeC4 2017-01-18 15:37:23 UTC #26

Bonjour,

Pouvez-vous nous donner une idée du moment où cela coupera ?
De mon côté, je suis dans une impasse :
- obligé de travailler avec un logiciel du type MySQL Workbench (impossible avec PhpMyAdmin)
- trop risqué de migrer vers une machine dédiée : tout marche très bien actuellement, alors qu'une machine dédiée est bien plus difficile à configurer/maintenir
- une migration vers un VPS impliquerait de migrer toutes nos données dessus : donc risques et charge de travail importante (surtout pour tout tester)

Quelles sont nos alternatives ? Nous avons migré nos domaines depuis 5 ans chez OVH, et une des raisons est que nous pouvions y administrer nos bases via un logiciel : impossible d'administrer 5 BdD avec PhpMyAdmin, encore moins de "naviguer dans la data" avec nos scripts MySQL (directement accessibles depuis notre logiciel Sequel Pro ou MySQL Workbench).

Par ailleurs, je ne vois pas l'intérêt d'avoir un utilisateur SSH en hébergement mutualisé "pro", si les tunnels ne peuvent pas fonctionner : que reste-il à faire ? Des commits avec git ? Lancer une commande PHP ?
Ne serait-ce pas plus adapté de maintenir la possibilité du tunnel sur le port 3306 ?

Bref, je ne veux pas revivre la situation que j'ai eu depuis 2 semaines, où je ne pouvais plus travailler correctement. Je comprend les raisons sécuritaires, mais je dois pouvoir effectuer mes tâches aussi.
Merci. Philippe

Ludo.H 2017-01-19 10:34:51 UTC #27

Bonjour,

Nous regardons pour le moment en interne pour savoir comment sécuriser nos serveurs SSH, tout en vous laissant l'accès aux bases pour vos clients lourds.

Plusieurs pistes sont possible mais impliquent elles mêmes des soucis de sécurité.
Plus d'information semaine prochaine.

En attendant, les SSH restent comme ils sont.

Cdt,

PhilippeC4 2017-01-19 10:36:25 UTC #28

Ok merci et bon courage.

SebastienF 2017-01-23 14:12:14 UTC #29

Espérons une solution !

Propulsé par Discourse, le rendu est meilleur avec le JavaScript activé

OVH Community

Bienvenue sur votre espace communautaire. Posez des questions, recherchez des informations, publiez du contenu et interagissez avec d’autres membres OVH Community.