Vous voulez utiliser un client externe pour vous connecter à une base de données MySQL sur un serveur Private SQL chez OVH ? Eh bien, ce n’est plus possible…

Ce problème date de 2017 où OVH avait découvert que ses connexions SQL via tunnel SSH, sur ses serveurs SQL privés servaient à certains utilisateurs de rebond vers d’autres serveurs sur internet. Il pouvait s’agir de pratiques légales ou bien de piratage mais cela est difficile à déterminer, OVH a donc décidé que cette pratique lui faisait courir un trop grand risque de sécurité et a fermé la possibilité de créer des connexions en tunnel SSH depuis ses hébergements mutualisés vers ses serveurs SQL privés (il en est de même pour les bases de données mutualisées).

Plus précisément, elle s’explique par le fait que le daemon SSH, sous Linux, ne permet par de créer des logs sur les connexions en tunnel. Il est donc impossible de déterminer à quoi elles servent et si elles sont impliquées dans des attaques de hackers. Faute de solution technologique viable pour assurer la sécurité de ce type de liaison, OVH a donc décidé de prendre cette décision qui consiste à interdire toute tentative de connexion via un tunnel SSH vers ses serveurs SQL privés.

Un handicap considérable pour les utilisateurs

Mais cette décision n’est pas sans conséquences car nous sommes nombreux à utiliser des connexions en tunnel pour atteindre nos bases de données. Il existe deux grands cas d’usage qui sont relatés dans cette discussion sur les forums ovh :

• WP-cli et les autres outils d’automation en ligne de commande

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

• Sequel, MySQL WorkBench, Navicat, etc.

(…) Idem pour moi avec Sequel Pro et MySQL Workbench, alors que tout fonctionnait parfaitement depuis des années (depuis 2011 je pense). (…)

Les développeurs et les intégrateurs sont donc nombreux à utiliser des applications de tous ordres pour les assister dans la gestion de leur base de donnée. Qu’il s’agisse de maintenance, de migration ou de développement pur, l’assistance de ces outils leur fait gagner un temps précieux. Temps qui est aujourd’hui perdu avec la contrainte d’utiliser des outils en ligne, plus lents et moins performants en terme de fonctionnalité.

Retour à PHPmySQL

La seule solution actuellement proposée par OVH consiste à revenir à la bonne vieille méthode : PHPmyAdmin. Les anciens le connaissent bien, mais personne ne l’apprécie vraiment. Il s’agit effectivement d’une application qui ne tire pas partie des avantages ergonomiques du javascript et de l’AJAX. Son utilisation est donc peu ergonomique et pas du tout intuitive. Vous l’aurez compris, je ne l’apprécie pas vraiment. Et si l’on poursuit la lecture du thread du forum OVH cité précédemment, je ne suis pas le seul :

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

C’est pour cette raison que les développeurs ne devraient pas être contraints à changer leurs habitudes de travail, surtout quand il s’agit d’abaisser leurs standards techniques, en raison d’un problème de sécurité mal géré par un hébergeur.

La solution : monter son propre serveur, qu’il soit dédié ou virtualisé…

Quand le problème est insoluble et qu’il faut malgré tout continuer à travailler, il faut bien finir par le contourner. La solution adoptée par la majorité des développeurs qui ont des notions en Linux et en hébergement consiste à monter son propre serveur de dev ou de prod, que ce soit sous la forme d’un dédié ou d’une virtualisation publique ou privée. Plus laborieuse à construire et à maintenir qu’un hébergement mutualisé, cette solution technique est bien évidement plus flexible car le développeur est ici maître chez lui. Il configure son serveur comme bon lui semble et il peut ouvrir l’accès SSH vers sa ou ses bases de données sans difficulté dans un tel environnement. Je précise qu’il s’agit bien d’héberger ses bases sur ce serveur fraichement construit et pas, une nouvelle fois, d’accéder à un serveur SQL privé OVH dans ce contexte.

Sinon, si vous ne vous sentez pas de recourir à cette solution, vous pouvez toujours tenter l’aventure avec un autre hébergeur, il en existe certainement qui autorisent la pratique du tunneling SSH vers SQL sur leur infrastructure.

Dites-nous dans les commentaires si vous connaissez des hébergeurs qui autorisent le tunneling sur leurs infrastructure mutualisée !