Bonjour,
Je me connecte habituellement à la base de données de mon site en SSH avec HeidiSQL (logiciel de gestion de base de données plus rapide et pratique que PHPMyAdmin). Sans problème jusqu'à ma dernière connexion vers mi-décembre, mais depuis mon retour, mes nouvelles tentatives échouent toutes. J'obtiens ce message :
> Lost connection to MySQL server at 'reading initial communication packet', system error: 0
La base n'est pourtant pas HS car je peux y accéder via PHPMyAdmin.
Étant donné que la configuration n'a pas changé pendant mon absence, je pense à un changement de config chez OVH (j'ai d'ailleurs vu plusieurs personnes avec des problèmes de SSH dans le forum). Que faire ?
PS : j'ai longuement cherché une solution avant de poster mais rien de concluant.
—
Mise à jour 02/03/17 : comme le sujet devient long, je synthétise la réponse ici : OVH a désactivé cette possibilité pour raisons de sécurité. Mais le débat reste ouvert car l'obligation de passer par PHPMyAdmin est handicapante pour pas mal de monde (v. la suite du sujet).
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.