Par mesure de sécurité, nous voulons nous connecter à MySQL en cours d'exécution sur EC2 via ssh. Nous avons d'autres serveurs où nous le faisons sans problème, mais pour une raison quelconque sur EC2, cela ne fonctionne pas. L'instance exécute Amazon Linux, MySQL est en version 5.5.42.
J'ai vérifié que l'utilisateur MySQL a les autorisations appropriées. J'ai ouvert le port 3306 dans les paramètres AWS et je peux me connecter à MySQL avec l'utilisateur et le mot de passe sans problème. Bien entendu, nous ne voulons pas laisser ce trou dans le pare-feu pour la production.
J'ai vérifié que l'utilisateur (actuellement en utilisant ec2-user pour les tests, j'utiliserai un utilisateur avec des autorisations restreintes pour la production) peut exécuter MySQL en ligne de commande sur EC2 et n'a aucun problème à établir une connexion SSH en utilisant la clé privée.
Voici la commande ssh que j'utilise pour établir le tunnel sur mon Mac:
ssh -nNT -L 3306:ADRESSEIP:3306 -i /chemin-vers/cle.pem ec2-user@ADRESSEIP
Ensuite, j'essaie de me connecter à MySQL. Cela reste bloqué. Si je ferme le tunnel, je reçois le message suivant:
Perte de connexion au serveur MySQL lors de la lecture du paquet de communication initial, erreur système : 0
Si je laisse le temps d'expiration, je reçois la même erreur de base:
Perte de connexion au serveur MySQL lors de la lecture du paquet de communication initial, erreur système : 35
et la commande ssh signale:
channel 2: ouverture impossible : échec de la connexion : délai d'attente de la connexion
Je tiens à préciser que j'utilise cette commande de base (moins la clé privée) pour établir des tunnels vers des serveurs non-EC2 avec succès tout le temps.
Si j'ajoute vvvv à la commande ssh, au moment où j'essaie de me connecter à MySQL jusqu'au moment d'expiration du délai, voici ce qui est rapporté:
debug1: Connexion au port 3306 pour la redirection vers le port 3306 vers l'ADRESSEIP demandée.
debug2: fd 7 réglage de TCP_NODELAY
debug3: fd 7 est O_NONBLOCK
debug3: fd 7 est O_NONBLOCK
debug1: canal 2: nouveau [direct-tcpip]
canal 2: ouverture impossible : échec de la connexion : délai d'attente de la connexion
debug2: canal 2: zombie
debug2: canal 2: collecte des déchets
debug1: canal 2: libération : direct-tcpip : écoute du port 3306 pour l'ADRESSEIP port 3306, connexion depuis l'adresse IP 127.0.0.1 port 49316, n canaux 3
debug3: canal 2: statut: Les connexions suivantes sont ouvertes :
J'ai également essayé d'utiliser un client appelé bitvise Tunnelier sous Windows et d'utiliser le pilote ODBC MySQL pour les tests et j'obtiens les mêmes résultats - lorsque je ferme le tunnel, je reçois le même message d'erreur, ce qui me conduit à conclure que le problème vient du serveur.
J'ai essayé quelques suggestions que j'ai trouvées concernant l'ajout de skip-networking à my.cnf et l'ajout de mysqld:ALL:ALLOW et mysqld-max:ALL:ALLOW à /etc/hosts.allow sans changements de comportement.
Je suis complètement perdu à ce stade. Je ne sais pas si c'est un problème de MySQL, un problème de SSH ou un autre problème de réseau EC2.