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.