Connexion MySQL sur tunnel SSH
J'ai mis en place un tunnel SSH entre deux serveursAetB.Ba un serveur MySQL, et cela fonctionne:
mysql -h localhost -P 3306 -u user -p
Bien que cela ne soit pas:
mysql -h 127.0.0.1 -P 3306 -u user -p
Bien que my.cnf ait ces lignes:
bind-address = 127.0.0.1
# Next addr differs slightly, but anyway
bind-address = 99.99.99.99
Maintenant à propos du tunnel. Il relie les éléments suivants: (A) localhost(9989) -> (B) localhost(3306) Mais quand (surA, avec les ports transférés) je le fais
mysql -v -h 127.0.0.1 -P 9989 -u user userdb -p
Je reçois ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
Et quand je le fais
mysql -v -h localhost -P 9989 -u user userdb -p
Je reçois ERROR 1045 (28000): Access denied for user 'user'@'localhost' (using password: YES)
Quelle pourrait être la raison? Qu'est-ce que je fais mal?
Il y a trois problèmes ici.
1 - Oubliez le tunnel SSH pour le moment
Vous ne pouvez pas lier MySQL à plusieurs adresses IP spécifiques . La première clause bind-address est remplacée (donc ignorée) par la seconde. Votre serveur n'écoute que 99.99.99.99.
La raison pour laquelle vous pouvez vous connecter avec -h localhost mais pas avec -h 127.0.0.1 est que, dans le premier formulaire, vous ne vous connectez pas réellement via TCP/IP, mais via un socket local.
Recherchez dans votre my.cnf une clause socket.
Supprimer une clause bind-address redondante. Vous voudrez peut-être utiliser bind-address=0.0.0.0, qui indique au démon MySQL d’écouter les interfaces all network.
2 - Configurons votre tunnel SSH
La raison de votre erreur ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0 ne m'est pas évidente. Le tunnel I suspect SSH est en fait établi uniquement lorsqu'il reçoit une demande de connexion (dans votre cas, lorsque vous exécutez le client mysql). Étant donné que votre serveur n'écoute pas 127.0.0.1 (voir le paragraphe précédent), le tunnel SSH ne peut pas être établi, la connexion échoue et votre client l'interprète comme une défaillance réseau.
3 - Pourquoi mysql -v -h localhost -P 9989 -u user userdb -p échoue
S'il vous plaît poster la sortie de
[modifier: venez d'ajouter ...OR Host LIKE 'localhost' ci-dessous, cela pourrait être utile pour le dépannage]
mysql > SELECT user, Host FROM mysql.user WHERE user LIKE 'user' OR Host LIKE 'localhost';
(remplacez 'user', après la clause LIKE, par le nom d'utilisateur réel si nécessaire)
Le contrôle d'accès MySQL vérifie le nom d'utilisateur/mot de passe (user) et l'origine de la connexion (Host) pour identifier un utilisateur. Vous n'avez probablement pas créé d'utilisateur 'user'@'localhost'.
NB: mysql.com étant inaccessible depuis mon emplacement actuel, je ne peux pas créer de lien vers les pages de manuel correspondantes.
Je viens de rencontrer ce problème même.
Dans mon cas, le serveur MySQL est configuré avec bind-address: 192.168.4.4. J'ai initialement configuré un tunnel SSH avec une chaîne -L 3306:localhost:3306 user@server communément mentionnée et, à partir de mon ordinateur, je me connecte avec mysql -h 127.0.0.1.
Cela ne fonctionne pas car MySQL n'écoute plus sur 0.0.0.0 ni même "localhost" (alias 127.0.0.1), uniquement 192.168.4.4.
La chaîne de tunnel correcte doit être -L 3306:192.168.4.4:3306 user@server. Cela indiquera à l'extrémité du tunnel distant de se connecter à MySQL à l'aide de l'adresse IP sur laquelle MySQL écoute réellement.
TUNNEL SSH ÉTAPE PAR ÉTAPE
--- DU CÔTÉ SERVEUR ----
dans la machine cible (pouvant être adressée par IP ou par un domaine hébergé), il existe un fichier de configuration /etc/mysql/my.cnf ayant une ligne
bind-address = 127.0.0.1
confirmé avec console
netstat -tapn | grep mysql
// tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 18469/mysqld
ce qui signifie que le serveur mysql ne répond qu'aux demandes de l'hôte local
--- CÔTÉ CLIENT ----
vous avez un compte (éventuellement une clé ssh) pour vous connecter avec cygwin, PuTTY ou linux_Shell
ssh user_name@Host_name
créer SSH TUNNEL
ssh -f -N -L 1000:127.0.0.1:3306 user_name@Host_name
ce qui signifie qu'il crée une connexion permanente depuis le port 1000 sur la machine que je tape (client) vers le nom d’hôte distant: 3306 .... 127.0.0.1 signifie ici le nom distant (nom_hôte) et ne doit pas être remplacé par mot_hôte_hôte établissez la connexion sur un socket (nommé) non par IP ... Vous obtiendrez 'ERROR 2002 (HY000): Impossible de se connecter au serveur MySQL local via le socket' /var/run/mysql.sock '(2 ) ' lors de la tentative de connexion de mysql
-f = aller en arrière-plan - N = aucune excution
à la fois -f -N genre de nohoop - vous pouvez fermer la console et les tunnels persistent
--- DU CÔTÉ SERVEUR ---
netstat -tapn | grep ssh
// tcp 0 0 server_ip:22 clint_ip:port ESTABLISHED 24915/sshd: user_name
ce qui signifie qu'il existe une connexion permanente via le protocole chut
--- CÔTÉ CLIENT ---
mysql -h 127.0.0.1 -P 1000 -u mysql_user -pmysql_pass
votre client mysql (côté client) est maintenant connecté au serveur mysql distant ... ici 127.0.0.1 est la machine cliente
idem pour workbench, heidiSQL
comment tuer les tunnels SSH
ps fax | grep ssh
kill process_id
J'ai eu le même problème ("Lost connection...") sous Windows (lors de l'utilisation du tunnel SSH via PuTTY). J'ai 2 problèmes ici:
- Un mauvais port a été utilisé, vérifiez si vous le configurez correctement
- J'ai oublié d'activer dans
PuTTY: Connection > SSH > Tunnels > Local ports accept connections from other hosts
Dans mon cas, une configuration du démon SSH bloquait le tunnel. AllowTcpForwarding doit être activé.
AllowTcpForwarding yes
Un simple pas a fonctionné pour moi… je vais partager cela, alors peut-être que certains d'entre vous pourront avoir la migraine épargnée.
MON REGLAGE
Dans mon cas particulier, j’ai un serveur Percona fonctionnant sous Ubuntu, connecté à MySQL Workbench (sur une machine virtuelle Windows) via SSH; le serveur a fonctionné correctement pendant plusieurs jours avant de générer une erreur 10060 lors du traitement d'une requête.
CE QUI A TRAVAILLÉ POUR MOI
J'ai découvert dans un forum de Acquia.com que, dans certains cas, le Workbench n'accepte pas "127.0.0.1" en tant qu'hôte. Vous devez donc le remplacer par "localhost". Je l'ai fait et cela a fonctionné (curieusement, le Workbench a demandé à nouveau les mots de passe, même s'ils étaient déjà stockés, mais fonctionnaient quand même).