J'essaie de me connecter à ma base de données via le tunneling SSH à partir de l'un de nos serveurs d'applications Web avec MySQL Workbench. Voici la configuration de base; notez que j'ai changé certaines valeurs dans la capture d'écran pour des raisons de sécurité.
Le problème est que chaque fois que j'essaie de me connecter via un tunnel SSH à partir de l'un de nos serveurs d'applications, j'obtiens l'erreur suivante:
Impossible de se connecter à us-east-1.amazonaws.com via le tunnel SSH à computer.amazonaws.com avec l'utilisateur social_shop_prod. Impossible de se connecter au serveur MySQL sur 127.0.0.1.
Cependant, si j'utilise les mêmes informations d'identification via SSH via la ligne de commande suivante:
mysql -u social_shop_prod -h us-east-1.amazonaws.com -p
Je peux me connecter avec succès et obtenir l'invite de commande interactive MySQL.
J'ai parlé avec le reste de mon équipe de développement ici et aucun de nous ne peut comprendre pourquoi je ne peux pas tunneler SSH depuis nos serveurs d'applications avec Workbench; mais quand je SSH à l'un de nos serveurs d'applications et que je me connecte à MySQL via la ligne de commande; Je peux me connecter avec succès.
Et pourquoi essaie-t-il de se connecter via 127.0.0.1? Je n'ai pas précisé cela dans la configuration; mon fichier d'hôtes ne redirige pas non plus les domaines indiqués ci-dessous vers cette IP.
Toute contribution constructive est grandement appréciée.
Puisque vous vous connectez via un tunnel SSH, cela signifie que le port MySQL 3306 de us-east-1.amazonaws.com est ouvert localement sur votre ordinateur. L'adresse IP de votre ordinateur est 127.0.0.1 ou localhost. Lorsque vous vous connectez au serveur mysql sur us-east-1.amazonaws.com, vous y accédez réellement via 127.0.0.1, c'est-à-dire votre ordinateur. Si vous aviez un autre tunnel ouvert ou MySQL fonctionnant localement sur votre ordinateur, il se peut que cet autre serveur MySQL rejette vos tentatives d'authentification
Il existe quelques tests que vous pouvez essayer:
1. Sur quels ports votre ordinateur Windows écoute-t-il
À partir d'une invite de commande: netstat -a (répertorie tous les ports ouverts)
Sous linux, ce serait: netstat -tlpn
2. Test de connectivité de base
À partir d'une invite de commande DOS ou d'une console Linux: telnet 127.0.0.1 3306
Si vous obtenez un temps mort ou si un autre programme répond, votre tunnel n'est pas configuré correctement.
. Modifiez le numéro de port que MySQL Workbench ouvre localement
Nous supposons que le plan de travail MySQL crée le tunnel sur votre ordinateur. Si c'est le cas, dans MySQL Workbench, essayez de passer par un autre numéro de port comme 9000.
Assurez-vous que 9000 n'était pas répertorié comme un port ouvert à partir de: netstat -a
Si vous avez accès ssh à us-east-1.amazonaws.com
4. Essayez de vous connecter à MySQL à partir de us-east-1.amazonaws.com
mysql -u myuser -h 127.0.0.1 -p
Et comme l'a dit Rolando, vous voudrez vérifier que vous vous connectez avec les bonnes informations d'identification. Par exemple, si vous vous connectez en tant que [email protected] et que vous avez un utilisateur myuser sans hôte, vous ne pourrez probablement pas vous connecter en utilisant [email protected].
La raison pour laquelle 127.0.0.1 est contacté est que le tunnel connecte un port de votre machine locale à l'hôte distant. Le message semble suggérer qu'une connexion SSH n'est pas établie.
Essayez ceci depuis la ligne de commande:
ssh -L 33000:remotehost:3306 user@remotehost
Assurez-vous que SSH autorise les ports redirigés; si vous recevez un message indiquant que le renvoi n'a pas été autorisé ou a été refusé, c'est pourquoi.
Pour résoudre ce problème, vous devez modifier la configuration du serveur; ajoutez cette configuration au serveur SSH:
AllowTcpForwarding yes
N'oubliez pas de redémarrer le serveur pour activer cette configuration.
J'ai continué à gérer ce problème pendant près de 2 semaines maintenant, j'ai réussi à le régler. Je le posterai ici pour que plus de gens puissent l'essayer.
Ok, j'utilise OpenSSH (natif Win10) et Workbench 8.
Pas à pas:
1. Ajoutez vos clés d'hôte SSH à l'agent à l'aide de ssh-add.
2. Générez les paires de clés à l'aide de ssh-keygen. Dans mon cas, ces fichiers vont automatiquement à Users/myUser/.ssh
selon les configurations d'installation.
3. Ajoutez la clé publique au fichier authorized_keys (qui doit se trouver dans le chemin d'installation de votre serveur, dans mon cas Windows/System32/OpenSSH/.ssh
) sans extensions.
4. Ajoutez les clés générées que vous venez de créer à l'agent à l'aide de ssh-add.
Les étapes ci-dessus sont à peu près la configuration d'un serveur SSH en ligne de commande que je suppose que l'OP a déjà fait pour sa connexion fonctionne via le terminal. Pour configurer MySQL Workbench 8, vous faites à peu près la même chose sauf que vous devez convertir le private_key.pem au format OpenSSH avant de les déplacer vers Users/myUser/.ssh
et OpenSSH_instalation_path/.ssh
User/myUser/.ssh
et OpenSSH_instalation_path/.ssh
OpenSSH_instalation_path/.ssh
dossier.User/myUser/.ssh
.MISE À JOUR: Vous devrez définir les éléments suivants dans votre fichier sshd_config:
PermitRootLogin sans mot de passe
PubkeyAuthentication oui
PasswordAuthentication no
PermitEmptyPasswords non
AllowTcpForwarding oui
LISEZ S'IL VOUS PLAÎT:
Je suis un analyste inexpérimenté, donc si un utilisateur plus avancé sait lequel des deux dossiers .ssh est le bon, veuillez nous le dire. Je trouve l'OpenSSH un peu ambigu à ce sujet.
Cela a fonctionné pour moi tout en définissant un environnement de développement local en utilisant uniquement localhost. Juste à des fins d'apprentissage.
Vous pouvez ajouter myUser @ localhost aux utilisateurs de MySQL Workbench avant de tester la connexion.
Si c'est vraiment nécessaire, je peux ajouter des images.
J'ai eu un problème similaire, et cela peut être évident, mais vérifiez les règles de pare-feu dans AWS. J'ai un ensemble de plages IP pour limiter les connexions du monde extérieur. Et l'IP de mon bureau a changé, elle est donc sortie de la plage IP. Mon collègue dans un autre bureau pouvait toujours se connecter, donc je pensais que le problème était sur mon PC, mais le problème était avec les règles de pare-feu dans AWS. J'espère que cela aide quelqu'un :)
Dans mon cas, le problème que j'ai dû revenir à un nom de domaine ou IP valide au lieu d'un hôte personnalisé localement est résolu.
/etc/hosts
)Je travaille avec un mécanisme de résolution des hôtes locaux qui définit:
#.#.#.# my-vm
Pour une raison quelconque avec MySQL 5.2.47
Sur Linux Mint 14 (Nadia)
qui est similaire à Ubuntu 12.10 (Quantal)
le le mécanisme de résolution ne fonctionne pas.
Simplement passez à un nom de domaine public tel que my-website.com
Résolvez le problème.
Voir ici pour une liste de ressources pour se connecter à diverses cibles (Amazon RDS, Amazon EC2, Windows Azure et autres): http://forums.mysql.com/read.php?152,252640,252640#msg -25264 .