Faire utiliser à MySQL le port TCP transféré

Évitez de sélectionner un socket Unix local lorsqu'un client MySQL est censé se connecter via un transfert SSH TCP.

Le transfert SSH écoute sur le port local 13306, mais mysql se connecte toujours à la base de données locale—ou signale que son socket local est absent. Sous Unix, un client MySQL à qui l'on donne localhost peut choisir un socket Unix plutôt que TCP. Fournir un port ne change pas nécessairement ce choix.

Pour un transfert TCP approuvé existant, rendez le protocole explicite :

mysql --protocol=TCP --host=127.0.0.1 --port=13306 \
  --user=dbuser --password

Le nom d'utilisateur est illustratif ; l'option de mot de passe demande une saisie interactive. La commande se connecte à l'écouteur TCP local au lieu d'un socket Unix.

Gardez les deux connexions séparées

Une route SSH fixe peut prendre cette forme :

ssh -N -L 127.0.0.1:13306:db.internal:3306 [email protected]

Le serveur SSH de la passerelle atteint db.internal:3306. MySQL authentifie ensuite le compte de base de données à travers ce flux d'octets. Une clé SSH acceptée n'accorde pas une connexion à la base de données, et les restrictions de source de la base voient la connexion arriver de ce côté de la route.

Il s'agit d'un adaptateur TCP fixe, et non d'un réglage SOCKS consommé par mysql. L'application n'a pas besoin de négociation SOCKS car le point de terminaison du transfert a une cible prédéfinie.

Conservez l'identité TLS prévue pour la base de données et la politique de certificats là où elles sont utilisées. Connecter le socket à loopback ne rend pas un certificat de base de données valide pour un autre nom de service. Une connexion TCP locale réussie tranche le choix du transport, pas l'authentification ultérieure de la base ni les contrôles TLS.

Articles similaires