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

Bonjour,

l'astuce du moment est d'activer l'environnement d'exécution "**Stable**"

Bonjour Buddy, merci pour ta réponse. Malheureusement j'ai activé le mode stable il y a plusieurs heures (j'étais en legacy) mais pas de changement...

Bonjour,

Nous rencontrons nous aussi le même problème décrit dans ce sujet. Nous utilisons SQLyog pour se connecter à nos base de données sans aucun problème jusqu'à la semaine dernière. Depuis début janvier, nous obtenons le même message :

> Error No. 2013
> Lost connection to MySQL server at 'reading initial communication packet', system error: 34

L'accès via PhpMyAdmin du manager est toujours possible. Nous avons aussi cherché une solution sans trouver... Et le service technique d'OVH au téléphone n'a pas su répondre à notre demande sur ce problème.

En espérant trouver une solution rapidement.

Bonjour,

vous essayez de vous connecte à des base SQL mutualisé ?

Si oui vous n'auriez jamais du pouvoir y accéder vu que OVH normalement bloque les connexions extérieur sur les SQL mutualisé pour que ceux-ci soit uniquement accessible en interne (cela inclus les SQL privé il me semble).

Cordialement, janus57

En passant par le tunnel ssh du Mutualisé ça marchait.

Il y a eu pas mal de sujet depuis le début de l'année avec le ssl, et la solution est de passer en environnement d'exécution stable pour régler le problème.

Passer en environnement stable permet de toute façon d'avoir les paquets à jour.

Bonjour,

et OVH n'aurait pas renforcer/modifier pour éviter ce genre d'utilisation (vu qu'a la base c'est seulement accessible en interne si on cherche pas à contourner) ?

Cordialement, janus57

Rebonjour,
2 jours après mon passage en "stable", la connexion ne fonctionne toujours pas. Y aurait-il d'autres paramètres à régler ? Un problème lié à des htaccess ? Ou à mon paramétrage en https ?

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 ?

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.

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.

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...

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.

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...

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

Bonjour,

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

depuis un poste personnel:

$ ssh mutu -L 3306::3306
@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,

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

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".)

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...

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.

Bonjour,

Vu le nombre de demandes, nous avons un petit peu creusé sur le sujet. Il s'agit bien d'une mise à jour qui a cassé ce type de tunnel, non prévu initialement.

En analysant plus précisement, nous nous sommes rendus comptes que les tunnels fonctionnent si on utiliser l'adresse IP locale de la base de données. Pour la connaître, vous pouvez vous connecter en SSH sur votre hébergement et faire un

ping nom.de.ma.base

Nous recherchons la cause de ce soucis afin de voir si nous pouvons le corriger simplement. En attendant, vous pouvez utiliser l'adresse IP à la place du nom de votre base afin de vous connecter.

Cordialement,
Vincent

Génial.....

Pour info cela fonctionne toujours avec un SQL Privé.

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.

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.

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

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,

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

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,

Ok merci et bon courage.

Espérons une solution !

Bonjour, Je reviens aux nouvelles. Des solutions ont elles été mises en place ?

Bonjour,

Pour le moment la solution de contournement consistant a utiliser l'ip du mysql plutôt que son nom fonctionne toujours.

Les SSH auront cepedant, sous peu, le TCPForwarding de supprimer, pour raison de sécurité.

Cdt,

Cela signifie t-il que l'utilisation de client MySql tels que Sequel Pro ne sera plus permise quelque soit la configuration ?

Allez-vous proposer une alternative ou doit-on envisager de migrer l'ensemble de nos comptes vers un autre prestataire ?

C'est une question importante, j'espère que nous finirons pas avoir une réponse claire.

Bonjour,

Les SSH auront cepedant, sous peu, le TCPForwarding de supprimer, pour raison de sécurité.

Je vous confirme en effet qu'a terme, il ne sera pas possible de se connecter sur une base de données depuis l’extérieur pour les offres mutualisées (base comprise dans l'offre ou Sqlprivé). Ceci pour des raisons de sécurité.

Cordialement
Guillaume F.

Bonjour,

J'aimerai savoir quand exactement le TCPForwarding va être supprimé.
J'ai perdu 2 semaines à travailler très lentement en janvier, suite à certains changements des admins (avant de trouver que l'IP du serveur MySQL pouvait être encore utilisée).
Je ne veux plus me retrouver dans cette situation.

Je ne migrerai pas mon compte vers une machine dédiée ou un VPS, car cela implique beaucoup plus de paramètres à maintenir. Et bien sur, c'est risqué, alors que notre site+services fonctionnent très bien actuellement.

En bref, j'ai l'impression qu'il faut que je me prépare à changer d'hébergeur.
Pour mon histoire, depuis 5 ans, j'ai migré tous les site+services de notre entreprise chez OVH car nous trouvions cela très bien intégré en mode mutualisé. L'utilisation de bases de données avec un outil spécialisé comme MySQL Workbench ou Sequel Pro étant un must-have : non, nous n'utilisons pas des bases de données de 2 GO avec PHPMySQL !

Pour moi, les admins ont décidé d'une régression fonctionnelle pour des raisons de sécurité. Ce qui n'est commercialement pas acceptable.
D'autant plus que nous avons souscrit à l'offre mutualisé "pro" pour travailler avec Sequel Pro. Quel est l'intérêt de se connecter en SSH désormais ? A part faire des commits avec git, je n'en vois pas.

Ne serait-ce pas plus adapté de maintenir seulement la possibilité du tunnel sur le port 3306 ?
Je ne vois pas en quoi c'est un problème de sécurité.

Bref, je comprend les raisons sécuritaires. Mais si cela m'empêche de faire mon travail, alors ce n'est pas acceptable en l'état.
Merci de m'avoir lu. Philippe

Bonjour,

Nous comprennons ce les soucis qu'engendre cette fermeture.
Il y a plusieurs soucis avec le forwarding, il y a des abus en cours, observé chez nous.
(nos serveurs SSH servent de rebonds a certain client pour se connecter autre part)

Ne serait-ce pas plus adapté de maintenir seulement la possibilité du tunnel sur le port 3306 ?

Il est possible de le faire, la close "PermitOpen" peut restraindre les connexions sur le 3306 par exemple, le soucis ici est que SSH ne log pas qui fait du tunnel vers où. Nous sommes aveugle de ce coté là. Quelqu'un de malveillant pourrait rebondir via le SSH et attaqué le port 3306 de nos mysql sans qu'on le voit.

Il est possible de patché SSH pour avoir des traces, cependant cela rendrait le package ssh difficilement maintenable.

Cdt,

Bonjour Ludovic,

Merci pour la réponse.
Si vous pouvez observer ces abus, pourquoi ne pas les empêcher, sans modifier la fonctionnalité pour les clients qui s'en serve correctement.
IE : ceux qui envoie une requête de l'exterieur vers l'intérieur. Et qui ne s'en serve donc pas pour mener des attaques à l'extérieur sous l'identité d'un serveur OVH (j'imagine que c'est votre souci).

Pourquoi ne pas limiter les tunnels en fonction de l'IP des serveurs MySQL ? Franchement, je ne vois pas qu'est-ce qu'on peut attaquer sur un serveur MySQL (faire un "flood", et encore, ya déjà des protections pour cela il me semble).
D'autant plus qu'il faut s'authentifier pour créer le tunnel SSH. Et donc, une mauvaise utilisation peut rapidement être bloquée au niveau de l'utilisateur (plus droit au SSH si utilisation frauduleuse).

Bref, si à toutes ces hypothèses, il y a une justification pour quand même arrêter le forwarding, alors quelles sont mes possibilités ?
Changer d'hebergeur ?
Migrer mes bases (et seulement mes bases) vers un autre serveur, style machine dédiée, que j'administrerais moi-même (perte de temps, mais bon ...), mais qui fonctionnera de paire avec mon hébergement mutualisé (auquel je ne veux pas toucher, car il marche très bien) ?

Et enfin, quand aura lieu l'arrêt du forwarding ? Combien ai-je de temps pour me retourner face à cette regression fonctionnelle ?

Merci. Philippe

Bonjour,

Franchement, je ne vois pas qu'est-ce qu'on peut attaquer sur un serveur MySQL (faire un "flood", et encore, ya déjà des protections pour cela il me semble).

Faire des tentatives de brute-force de votre mot de passe.
Comme je l'indiquais, on ne le verrais pas, car SSH ne log pas les connexions forwarding.

Je vais faire des tests plus poussé aujourd'hui sur du "bridage" de forwarding.

Changer d'hebergeur ?

On ne peut pas vous forcer à rester, mais ce serait vraiment dommage.

Migrer mes bases (et seulement mes bases) vers un autre serveur, style machine dédiée

Oui c'est une solution, ou prendre un DBaaS en runabove chez OVH.

Et enfin, quand aura lieu l'arrêt du forwarding ? Combien ai-je de temps pour me retourner face à cette regression fonctionnelle ?

Je pense que semaine prochaine, les upgrades devraient commencer.

Cdt,

Bonjour Ludovic,

Ca serait vraiment top de trouver une solution. Nous avons 6 hébergements chez OVH, dont 3 mutualisé pro qui ont absolument besoin de travailler avec un vrai logiciel MySQL (surtout pas PhpMyAdmin ou le terminal).
Et je n'ai pas envie de changer, mais la semaine prochaine c'est tellement proche ...

J'ai regardé un peu les DDaaS (https://www.runabove.com/SaaSDBMySQL.xml) mais c'est encore en beta ...
Ceci dit, j'ai essayé, et çà fonctionne correctement avec Sequel Pro ou MySQL Workbench. C'est une base de données somme toute très classique, une fois configurée.
Bref, cela semble etre une alternative plausible, même si cela m'ennuie un peu de passer du temps à tout retester les fonctionnalités de nos services une fois en place (quand bien même, notre code est bien mutualisé, l'accès aux bases se faisant à travers un seul point). Et reste le problème de l'évolution du service en prod (c'est dans le lab d'OVH pour l'instant, pas encore entérinné par OVH).

Bon courage. Philippe

Ici on gère une quarantaine de base de données avec Sequel, ainsi que 3 sql privé.
La perte de ces outils est aussi une énorme gène dans notre travail et nous fait perdre beaucoup de temps.

Bonjour Sébastien,

Vous pouvez toujours utiliser Sequel Pro : il vous faut trouver simplement l'adresse IP de votre serveur MySQL. Quelques commentaires plus haut, j'explique comment.
Mais bon, cette technique va être caduque dans quelques semaines j'ai l'impression ...

Bonne journée. Philippe

Bonjour,

La mise en production de la coupure du forwarding est faite.

Cdt,

Ouais je commence à la sentir passer ...
C'est vraiment super regretable. Mais bon, j'ai pas eu l'impression qu'on se soit soucié de notre sort.

Bonjour,

Suite à votre mise en production de la coupure du forwarding, il y a t'il la possibilité de continuer à utiliser un logiciel tel que SQLyog en utilisant une base de données SQL Privé ou Start SQL, ou par l'intermédiaire d'une option payante ?

Merci, Thomas

Bonjour,

ceci est vraiment très ennuyeux. Phpmyadmin n'est pas du tout au niveau pour travailler sur un vrai site de production.

Je peux comprendre les problèmes liés au tunneling ssh, mais ce tunneling était déjà lui-même une astuce pour résoudre le vrai problème, qui s'énonce simplement : accéder à la base de données avec un client lourd.

Merci de revenir vers nous avec une solution.

Bien cordialement

Bonjour @Ludo.H

Suite à un appel auprès du support ce matin je découvre (avec désespoir...) ce topic qui confirme nos bloquages depuis plusieurs semaines.
De même que toutes les autres personnes concernées nous gérons 70 noms de domaines et 40 hébergement (Pro et Perf) pour nos clients avec au moins 2 BDD pour chaque (une prod et une preprod)
Etant sous Mac tous les dév utilisent Sequel avec le tunnel SSH et **ce bloquage est une vrai régression**.

Nous recommandons OVH à tous nos clients entre autre pour cette fonctionnalité.
Déjà que vous bloquez la liaison avec les dépôt Git distants (obligé de faire un dépôt local, donc gérer 2 remotes : 1 origin et 1 ovh) cette nouvelle limitation remet vraiment en question le choix d'OVH dans notre cas.

Comme beaucoup l'on dit plus haut je n'estime pas pouvoir gérer de manière professionnelle un site en production régulier avec PhpMyAdmin !
Pour autant les solutions alternatives de type VPS ou SQL SaaS ne sont pas compatibles avec le cloisonnement des sites que l'on gère pour nos clients et on a pas vocation a être des Admin Sys et maintenir un dédié. (ça on l'a pour les "gros client" qui ont les moyens d'avoir de l'infogérance)

OVH a désormais les mêmes limitations techniques que 1&1... si c'est pas dramatique ça :(

Bonjour,

Avec du sqlprivé ou du dbaas c'est tout à fait possible de continuer à travailler avec Sequel avec un tunnel SSH.

Cdt,

Avec du sqlprivé ou du dbaas c'est tout à fait possible de continuer à travailler avec Sequel avec un tunnel SSH.

Pourtant impossible de se connecter avec Sequel sur du SQL privé de notre côté pour le moment.
Même message d'erreur que pour les mutu sous Sequel

_Impossible de se connecter à l'hôte sd70340-001.privatesql, ou la requête a expirée._
_MySQL a retourné : Lost connection to MySQL server at 'reading initial communication packet', system error: 0_

Que ce soit avec comme nom d'hôte sd70340-001.privatesql ou privatesql034 (et le bon port évidemment) même problème.

Si vous confirmez que c'est bien _sensé_ marcher avec du SQL privé ça nous sauverait la mise...!

Bonjour,

Il a du SSH avec le SQL privé, le serveur SSH est embarqué dans le containeur avec le MySQL.
Vous pouvez monter un tunnel, faudrait que je vérifie la conf sshd, du genre :

`ssh -L mylocalport:127.0.0.1:3306 privatesqlxxx.p19.paas.ovh.net`

A tester, mais cela devrait fonctionner.
Cdt,

@Ludo.H @GuillaumeF

J'ai testé dans tous les sens et même sur le SQL privé toujours impossible de se connecter avec un client lourd via SSH.
Ok pour optimiser la sécurité, c'est votre métier et c'est pour ça qu'on aime être chez vous.
Mais ce qui m'agace dans cette décision c'est la politique restrictive mise en place depuis janvier à cause des abus de quelques uns qui bloquent tout le monde et sans aucune alternative viable. Ca ressemble pas à la politique d'OVH à laquelle on était habitué...

Bonjour,

Avez-vous un ancien sqlprivé ou un nouveau ?
Les anciens ont une ip en 10.x et sur le port 3306
Les nouveaux n'ont pas d'ip attribué et sont sur un port de type 35xxx

Cdt,

Bonjour,
Y-a-t-il du nouveau depuis la dernière réponse de Ludo.H du 3 Mars 2017 ?
J'ai beau essayé de retourner les codes d'accès, les IP, les hôtes dans tous les sens, toujours impossible de se connecter à un SQL Privé à travers HeidiSQL.
Merci d'avance pour vos infos, cordialement

Vous parler d'un SQL privée ou des bases mutualisés ?

Apparement pour les bases Mutualisées c'est définitivement fermé.

Je parle bien d'un SQL Privé pour ma part.
Je suis désolé si ce fil de discussion ne concerne que les bases mutualisées...
Le technicien OVH que j'ai contacté m'a renvoyé ici pour obtenir ma réponse.
Malheureusement, la discussion n'indique pas clairement si c'est possible ou non.
Merci

Bonjour à tous,
Suite à de nombreux échanges avec l'assistance technique d'OVH, je vous confirme qu'il n'est pas possible d'utiliser un client MySQL (HeidiSQL, MySQL Workbench, Sequel Pro, etc...) pour administrer les bases de données mutualisées et les SQL Privé.
En espérant que cette fonctionnalité revienne dans le futur, bonne continuation à tous

Bonjour à tous,

Avez vous avancé sur une manière de gérer les bases SQL privées sans SSH ?
J'utilise Sequel Pro, et sans le SSH, ca va être vraiment galère (base de 700Mo).

Merci.

Pas de retour, je vais devoir allez chez un autre provider pendant l'été ?

Bonjour Buddy, merci pour [url=http://www.comparateur-mutuelle-assurance-sante.com]mutuelle retraités[/url] ta réponse. Malheureusement j'ai activé le mode stable il y a plusieurs heures (j'étais en legacy) mais pas de changement...

Bonjour,
C'est bien aussi d'activé ce mode!
Moi je le fais de temps en temps.

Bonjour,

Suite aux discussions que nous avions eu sur ce thread il y a quelques mois, nous avons avancé afin de vous permettre de vous connecter sur vos bases.

Nous allons proposer ce service d'ici quelques semaines pour les bases de données SQL privées : il sera possible d'activer une connexion au port 3306 pour une IP externe, et ainsi, de se connecter directement sur votre base de données.

Ce service n'est pour le moment accessible que sur les Cloud DB. Mais vous pouvez bien entendu prendre une Cloud DB à la place de votre SQL privé : c'est le même prix.

Bien cordialement,
Vincent

Aaaah ça c'est cool !
On va attendre bien sagement l'option sur les SQL privés car on a des dizaines de clients avec un Performance et pas le courage de migrer toutes les bases sur ClouDB.
En tous cas heureux de constater qu'OVH écoute (toujours) ses clients :)

Y'a une roadmap dispo quelque part publiquement ?

Merci @vcasse !

Bonsoir,

Est-ce que l'ouverture aux bases privées est une première étape avant l'extension aux offres mutualisées, ou est-ce que seules les privées en bénéficieront ?

Sans trop entrer dans les détails, quelle solution sécurisée avez-vous trouvée ?

(PS pour les modos : le message de KalysA 3 posts plus haut est un spam, il a inséré un lien vers une mutuelle dans sa citation.)

Nous n'avons pas encore établi de date précise mais c'est une question de semaines.

Nous n'avons pas prévu de le faire pour les bases de données mutualisées : cela nous demande une infrastructure plus conséquente (monitoring des connexions, bande passante ...) et ce coût n'est pas inclus dans ces bases de données.

Pour la solution, nous assurons l'ouverture de certaines IP en whitelist sur les SQL privés. Il faut donc déclarer votre IP afin de pouvoir vous connecter directement sur le serveur web.

Cordialement,
Vincent

Bonjour,

Où dois-je déclarer mes IP pour les mettre en whitelist sur mon sql privé ?

Merci.

A mon avis cette api peut servir : https://api.ovh.com/console/#/hosting/privateDatabase/%7BserviceName%7D/whitelist#POST

Merci Boulvard !

J'ai testé mais j'obtiens "Action possible only for public instance". J'ai une offre "Classic" à priori. Où puis-je changer ce paramètre ?

Je test dans la journée et te fais un retour ^^

Bon a priori ce serait plutot lié à Dbas (je pense) et pas encore au sql privé mutu. My bad.

Dommage, donc toujours pas de solution... Un hebergeur comme ovh qui nous bloque un accès tellement vital pour nous client, j'ai du mal à saisir.

Nous allons proposer ce service d'ici quelques semaines pour les bases de données SQL privées : il sera possible d'activer une connexion au port 3306 pour une IP externe, et ainsi, de se connecter directement sur votre base de données.

Bonjour, avez-vous du nouveau concernant les délais de mise en place de cette fonctionnalité sur les SQL privé ?
On a hâte...!

Pour la communauté : comme je resterai en mutualisé, je suis en quête d'une interface **web** alternative à PHPMyAdmin (ça, ça fonctionne encore). J'en ai trouvé plusieurs sur Google. J'ai testé http://topnew.net/sidu/ Sidu mais je n'ai pas été convaincu : quelques avantages par rapport à MyAdmin (tableaux plus lisibles, édition directe) mais interface vieillotte et pas du tout aussi pratique que le client que j'utilisais avant.

Avez-vous d'autres alternatives à suggérer ?

Bonjour,

avez-vous vu : https://www.adminer.org
Certains hébergeurs maintenant propose phpMyAdmin + Adminer
Sinon je suis aussi tombé sur https://sourceforge.net/projects/phpminiadmin/

Cordialement, janus57

Avez-vous d'autres alternatives à suggérer ?

--> https://www.wordetweb.com/word-et-web/OVH-eskuel-remplace-phpmyadmin-installez-votre-site-en-1-clic-FR.htm OVH - eSKUEL - Accès aux bases « 1 clic » d’OVH

Bonjour,
je tombe sur ce fil après avoir la fameuse erreur "Lost Connection", et bien mon sentiment c'est que messieurs d'OVH vous n'êtes pas très respectueux de vos clients OVH.

Vous décidez de supprimer ce type de connexion, sans même prendre le temps de faire un mailing à vos clients. Enfin plutôt, vos sous-clients, les petits, les mutualisés, qu'ils se débrouillent!!!
Outre le mépris apparent de votre démarche, je m'interroge sur la légalité de la chose. Quand j'ai souscris mon offre OVH cette possibilité était un point important pour moi. Les contrats sont payés d'avance pour une durée minimale d'un an, si vous en modifiez le contenu, sans l'accord de l'autre parti le contrat est rompu. Quand on passe un contrat on le respecte. Mais non OVH méprise également ses clients sur ce point

Contacté aujourd'hui sur ce point, le "support" (celui qui peut mettre jusqu'à 3 mois pour répondre à une demande d'incident), m'envoi évidement sur les roses, en invoquant la sécurité.. Mais quand OVH m'a proposé l'offre les contraintes étaient les mêmes, alors de quel droit modifier?

Le technicien support me rassure quand même en me disant que "Par contre, la connexion en SSH depuis l'adresse IP de votre hébergement mutualisée OVH reste toujours permise." Comme OVH est généreux !!!!! Une offre d'hébergement avec un accès SSH!!! mais on rêve.

Une petite suggestion pour les "cerveaux" de la sécurité OVH, coupez carrément les accès SSH, FTP, et HTTP de vos mutualisés, vous aurez moins d'ennuis!!!


Je suis client OVH depuis 10 ans et franchement je suis de plus en plus déçu par le comportement de l'équipe. Vous n'êtes même plus l'ombre de ce que vous avez été en relation clientèle..

Alors à toute personne qui lira ce message sachez que si vous prenez une offre mutualisée chez OVH, pour le prix vous n'aurez droit ni à la considération, ni au respect. Vous n'aurez même pas la garantie de conserver les services achetés lors de la souscription de l'offre.

Bonjour, des nouvelles sur ce sujet ?
Il était question de pouvoir autoriser une IP à se connecter "en direct" à une instance SQL privé.
Y a-t-il une roadmap ou une date prévue ?

D'avance merci de votre retour.

Bonjour à tous,

Si vous souhaitez accéder à votre base de données depuis une interface externe, vous pouvez désormais utiliser le produit CloudDB : https://www.ovh.com/fr/cloud/cloud-databases/

CloudDB est un produit issu de la R&D effectué sur les privateSQL et permet d'avoir une base de données sans gérer l'infrastructure sur des serveurs dédiés, vps, cloud serveurs mais aussi sur les hébergements web.

Sur ces bases de données, vous avez la possibilité d'autoriser une ou plusieurs IP externe à se connecter sur votre instance, et ainsi, utiliser un logiciel de gestion de base de données externe.

Bonne fin de semaine,
Vincent

Bonjour @vcasse,

Merci pour cette info, mais c'est pas vraiment une nouveauté sur le CloudDB.
Notre problème (et celui de tous ces de ce thread) c'est qu'on gère dans 90% des cas des hébergement mutualisé Performance pour nos clients qui embarquent par défaut un PrivateSQL et non pas un CloudBD.
Donc a moins que vous ayez prévu un outil magique de migration d'un SQL privé vers votre CloudDB sans frais, on est toujours au même point...

Pourquoi ne pas avoir la même fonctionnalité pour le SQL Privé ?

CloudDB est un produit issu de la R&D effectué sur les privateSQL et permet d'avoir une base de données sans gérer l'infrastructure sur des serveurs dédiés, vps, cloud serveurs mais aussi sur les hébergements web.

Salut,
J' ai meme probleme. Bien travaille avec HEIDISQL avec autres hebergements. Mais chez OVH ca ne marche pas. Configure Heidi connection a travers SSH, mais il met la meme erreur (Lost connection to MySQL server at 'reading initial communication packet', system error: 0).
Mais il est possible de ce connecter directement par Putty (prealable cochez SFTP " Active" dans l'onglet FTP-SSH dans votre Espace client OVH)

Merci de qq astuce pour resoudre la.

cdlt,
Egons

Bonjour, je vous invite à relire les fils précédent et vous aurez la réponse à votre question...

Bonjour @EgonsM , je vous invite à relire les fils précédent et vous aurez la réponse à votre question.

Bonjour à tous,
petit retour d'expérience pour avancer sur ce problème en optant pour un CloudDB comme suggéré par @vcasse un peu plus haut.
L'interface permet de whiteliste une IP et établir ainsi une connection direct avec Sequel... enfin !!
Sauf qu'après quelques tests, petite douche froide, la commande "mysql" ne permet pas de se connecter au serveur distant depuis un terminal SSH.

`mysql --host=monhost.dbaas.ovh.net --user=USER --port=123456 --password=***** DB`
`ERROR 2003 (HY000): Can't connect to MySQL server on '1006.dbaas.ovh.net'006.dbaas.ovh.net' (111)`

Même chose avec php-cli, la connection est tout simplement refusée. (Alors que le site fonctionne)

`Warning: mysqli_real_connect(): [2002] Connection refused (trying to connect via tcp://monhost.dbaas.ovh.net:35338)`

**Moi :** _Par contre pourquoi "le cloudDB ne supporte pas le SSH actuellement" ? C'est temporaire ?_
**OVH :** _Oui en principe le non support du SSH est temporaire. Mais je ne pourrais pas vous dire les raisons, il faudrait que je fasse une remonté aux équipes concernées. Je vous reviendrais dans les meilleurs délais._
**OVH :** _Je vous confirme que c'est temporaire. Par contre je ne peux pas vous préciser une date de mise en place._

Conclusion : un pas en avant, mais deux pas en arrière...

Bonjour,

Avez vous whitelisté l'adresse IP de la paserelle de sortie de votre cluster ?
https://docs.ovh.com/fr/hosting/liste-des-adresses-ip-des-clusters-et-hebergements-web/#cluster-025

Sinon, nos clusters n'ont pas le droit de communiquer avec votre base de données.
Cordialement,
Vincent

Bonjour @vcasse,
Oui comme précisé dans mon post le problème ne vient pas de là. Réponse de vos collègues ce matin :

> Je vous confirme que l'erreur que vous avez est lié au fait que pour le moment
CloudDB ne support pas les connexion en ligne de commande (SSH, php cli etc).
Il ne m'a pas été possible d'avoir une date précise de la mise en place de ce
type de connexion sur CloudDB. J'en suis navré.

C'est tout de même super limitant de pas pouvoir faire de requêtes sur une base de données depuis l'hébergement. Exit une maj de Symfony avec Propel, wp-cli pour WordPress et n'importe quel script qui permet de dumper la base par exemple... Vraiment déçu alors qu'il avait tout pour être prometteur en remplacement des SQL privé.

Bonjour,

Il n'y a effectivement pas de SSH sur les CloudDB qui sont des bases de données pures.
Cependant, vous pouvez vous connecter à votre CloudDB depuis le SSH de votre hébergement sans aucun soucis. Pour cela, il vous suffit de whiteliste l'adresse IP de la passerelle de sortie de votre cluster.

Cordialement,
Vincent

Bonjour @vcasse

> Cependant, vous pouvez vous connecter à votre CloudDB depuis le SSH de votre hébergement sans aucun soucis.

Bah non justement, c'est bien le problème !

Depuis un hébergement OVH (avec l'IP du cluster 21 whitelistée) j'ai ce message :

> mysql --host=1006.dbaas.ovh.net006.dbaas.ovh.net --user=test --port=35338 --password=***** DB
> ERROR 2003 (HY000): Can't connect to MySQL server on '1006.dbaas.ovh.net'006.dbaas.ovh.net' (111)

Bonjour,

c'est bien "91.134.248.245" que vous avez whitelisté ?

Cordialement, janus57

@janus57

Oui, c'est bien celle indiquée comme **passerelle de sortie de votre hébergement (gateway)**
du cluster 21

Ok, étrange.

Je regarde et vous tiens informer.

Cordialement,
Vincent

Bonjour, @Spyrit
J'ai encore se trouve sur cet sujet de non possibilité de ce connecter a MySQL installe sur OVH Cloud.
Que soit l'essence du sujet - OVH ne laisse pas connecter? Ou je dois acheter qq chose en plus?

Merci en avance pour clarification

Bonjour,

Juste parce que je viens d'avoir le problème et que ce post remonte assez facilement dans les recherches, je confirme qu'il n'est toujours pas possible en janvier 2020 de se connecter autrement qu'avec un phpMyAdmin à un BDD OVH mutualisée ou SQL Privé. Réponse du support OVH :
> La connexion à distance n'est pas possible avec un SQL privé, seul l'offre Cloud DB permet cette action. La connexion au SQL privé doit se faire en interne uniquement.

Ça a le mérite d'être clair.