MySQL connexion via le tunnel SSH
J'ai mis en place un tunnel SSH entre les deux serveurs Un et B. B a serveur MySQL, et cela fonctionne:
mysql -h localhost -P 3306 -u user -p
Alors que ce n'est pas le cas:
mysql -h 127.0.0.1 -P 3306 -u user -p
Bien que mon.cnf a ces lignes:
bind-address = 127.0.0.1
# Next addr differs slightly, but anyway
bind-address = 99.99.99.99
Maintenant sur le tunnel. Il relie le suivant:(A) localhost(9989) -> (B) localhost(3306)
Mais quand (sur Un, avec les ports transmis) je ne
mysql -v -h 127.0.0.1 -P 9989 -u user userdb -p
- Je obtenir ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
Et quand je ne
mysql -v -h localhost -P 9989 -u user userdb -p
- Je obtenir ERROR 1045 (28000): Access denied for user 'user'@'localhost' (using password: YES)
Quelle pourrait être la raison? Ce que je fais mal?
Vous devez vous connecter pour publier un commentaire.
Il y a trois questions ici.
1 - Oublier le tunnel SSH pour l'instant
Vous ne pouvez pas lier MySQL à plus d'une adresse IP spécifique.
La première
bind-address
alinéa est remplacé (par conséquent, pris en compte) par le second. Votre serveur est à l'écoute de99.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 la première forme, vous n'avez pas réellement se connecter via TCP/IP, mais à travers un socket local.Regarder dans votre
my.cnf
pour unsocket
clause.Supprimer un redondante
bind-address
clause. Vous souhaiterez peut-être utiliserbind-address=0.0.0.0
, qui indique démon MySQL pour écouter tous interfaces réseau.2 - permet l'installation de votre tunnel SSH
La raison pour vous d'erreur
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
n'est pas évident pour moi. Je suspect tunnel SSH est effectivement mis en place uniquement lorsqu'il reçoit une demande de connexion (dans votre cas, lorsque vous exécutez lemysql
client). Depuis votre serveur n'écoute pas 127.0.0.1 (voir le paragraphe précédent), le tunnel SSH ne peut être établie, la connexion échoue, et le client, et l'interprète comme une défaillance du réseau.3 - Pourquoi
mysql -v -h localhost -P 9989 -u user userdb -p
échoueVeuillez envoyer la sortie de
[edit : juste ajouté
...OR host LIKE 'localhost'
ci-dessous, comme cela pourrait être pertinent pour des fins de dépannage](remplacer
'user'
, après laLIKE
clause, avec le nom réel de l'utilisateur si nécessaire)MySQL de contrôle d'accès vérifie à la fois 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éer un utilisateur'user'@'localhost'
.N. B.: mysql.com étant inaccessible à partir de ma position à ce moment, je ne peux pas lien vers la pages de manuel.
bind-address=0.0.0.0
, qui indique à MySQL démon pour écouter sur toutes les interfaces réseau.". Vous êtes la plupart de bienvenue.mysql -hlocalhost
, le client utilise le socket.mysql -h127.0.0.1
explicitement indique au client pour l'utilisation de TCP/IP. Socket Local sont plus efficaces, car ils contournent la couche réseau.Je viens de rencontré ce problème.
Dans mon cas, le serveur MySQL est configuré avec
bind-address: 192.168.4.4
.J'ai à l'origine de l'installation d'un tunnel SSH avec la plus souvent mentionnée
-L 3306:localhost:3306 user@server
chaîne et à partir de mon ordinateur de se connecter àmysql -h 127.0.0.1
.Cela ne fonctionne pas parce que MySQL n'est plus à l'écoute sur 0.0.0.0 ou même
"localhost"
(aka 127.0.0.1), seulement192.168.4.4
.Le bon tunnel chaîne doit être
-L 3306:192.168.4.4:3306 user@server
.Ceci permet d'indiquer la distance de fin du tunnel pour se connecter à MySQL en utilisant l'IP MySQL écoute vraiment sur.
ÉTAPE-PAR-ÉTAPE SSH TUNNELING
--- CÔTÉ SERVEUR ----
dans la machine cible (qui peut être addresed par IP ou un domaine hébergé) il y a le fichier config /etc/mysql/my.cnf d'avoir une ligne
confirmé avec la console
ce qui signifie que le serveur mysql ne répondra qu'à la demande de l'localhost
--- CÔTÉ CLIENT ----
vous avez un compte (éventuellement une clé ssh) pour vous connecter à l'aide de cygwin,de mastic ou d'un linux_shell
créer un TUNNEL SSH
qui signifie hey ssh créer une connexion permanente à partir du port de 1000 sur la machine que j'type (client) à distance host_name:3306 .... 127.0.0.1 signifie ici la distance (hostname) et ne doit pas être remplacé par localhost mot parce que cela permettra de faire le lien sous unix (nommé) prise non pas par IP ... Vous obtiendrez 'ERREUR 2002 (HY000): can't connect to local MySQL server through socket '/var/run/mysql.sock' (2)' lors de la tentative de co connecter mysql
-f = aller à fond
-N = n excution
deux -f -N type de nohoop - vous pouvez fermer la console et les tunnels persistent
--- CÔTÉ SERVEUR ---
qui signifie qu'il ya une connexion permanente à travers shh protocole
--- CÔTÉ CLIENT ---
maintenant votre (côté client) le client mysql est connecté à un serveur mysql distant ... ici 127.0.0.1 est l'ordinateur client
même pour workbench, heidiSQL
comment tuer les tunnels ssh
J'ai eu le même problème (
"Lost connection..."
) sur Windows (en utilisant le tunnel ssh via Putty). J'ai 2 questions se posent ici:Putty: Connection > SSH > Tunnels > Local ports accept connections from other hosts
Dans mon cas, une configuration dans le démon SSH, était de bloquer le tunnel. AllowTcpForwarding doit être activé.
Une simple étape a fonctionné pour moi... je vais partager cela, alors peut-être que certains d'entre vous l'on peut épargner des maux de tête.
MON RÉGLAGE
Dans mon cas particulier, j'ai un Percona server en cours d'exécution sur Ubuntu, connecté à MySQL Workbench (dans une VM Windows) via SSH; le serveur fonctionnait bien pendant plusieurs jours avant de cracher une erreur 10060 lors du traitement d'une requête.
CE QUI A FONCTIONNÉ POUR MOI
J'ai trouvé dans un forum de Acquia.com dans certains cas, le Workbench n'accepte pas '127.0.0.1' en tant qu'hôte, vous devez changer en "localhost". Je l'ai fait, et ça a fonctionné (bizarrement, le Workbench demandé pour les mots de passe encore, même si elles ont été déjà enregistrées, mais a néanmoins).