web-dev-qa-db-fra.com

comment se connecter au serveur mongodb via le tunnel ssh

C'était facile pour moi de me connecter à mon serveur mysql distant sur AWS en utilisant un sequelpro , cependant j'ai du mal à faire la même chose avec mongodb.

J'ai essayé de configurer un tunnel ssh via la ligne de commande comme ceci:

ssh -fN -l root -i path/to/id_rsa -L 9999:Host.com:27017 Host.com

Je l'ai également essayé en remplaçant l'hôte par une adresse IP

l'idée est de transmettre toutes les connexions mongodb sur le port 9999 à celle sur l'hôte sur le port 27101 .. cependant quand j'exécute la commande:

mongo --Host localhost --port 9999

la connexion échoue, j'obtiens ceci à la place:

MongoDB Shell version: 2.6.0
connecting to: localhost:9999/test
channel 2: open failed: connect failed: Connection timed out
channel 3: open failed: connect failed: Connection timed out
2014-05-22T14:42:01.372+0300 DBClientCursor::init call() failed
2014-05-22T14:42:01.374+0300 Error: DBClientBase::findN: transport error: localhost:9999 ns: admin.$cmd query: { whatsmyuri: 1 } at src/mongo/Shell/mongo.js:148
exception: connect failed

si je lance Sudo netstat -plnt J'obtiens ce qui suit (qui semble en ordre):

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name   
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      4242/node           
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1342/httpd2-prefork 
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      2552/sshd           
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      2505/master         
tcp        0      0 127.0.0.1:27017         0.0.0.0:*               LISTEN      11719/mongod        
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      16561/redis-server  

une idée de ce que je fais mal?

mise à jour: voici à quoi ressemble la commande fonctionnelle finale (crédit revient à kenster ):

ssh -fN -i ~/path/to/id_rsa -L 6666:localhost:27017 [email protected]

où le -fN commande faire exécuter cette commande en arrière-plan

18
abbood

Les lignes "canal 2" et "canal 3" proviennent de ssh. L'instance sshd sur le serveur distant tente de se connecter au port Host.com 27017 afin de desservir une connexion de tunnel et obtient une erreur de "connexion expirée".

En d'autres termes, sshd sur le serveur distant ne peut pas atteindre la cible du tunnel. Étant donné que l'hôte distant est également l'hôte vers lequel vous êtes supposé tunneler, il est difficile de dire quel est le problème spécifique. Il se peut que "Host.com" résout plusieurs adresses IP. Vous établissez une connexion SSH avec un serveur du cluster, puis un autre serveur du cluster est choisi comme cible du tunnel. Vous pouvez essayer de changer la cible du tunnel en "localhost" au lieu de "Host.com":

ssh -fN -l root -i path/to/id_rsa -L 9999:localhost:27017 Host.com

Mise à jour:

"-L 9999: localhost: 27017" signifie que le client ssh sur le serveur local écoute les connexions sur le port 9999. Lorsqu'il obtient une connexion, il tunnelise la connexion vers l'instance sshd sur le serveur distant. L'instance distante sshd se connecte de là à localhost: 27017. Donc, "localhost" est ici du point de vue du serveur distant.

Avec la sortie netstat, il est un peu plus clair pourquoi cela ne fonctionnait pas auparavant. La partie "127.0.0.1:27017" signifie que Mongodb est spécifiquement lié à l'interface localhost (127.0.0.1) sur l'hôte distant. Vous ne pouvez pas contacter directement cette instance de mongodb en essayant de vous connecter à l'adresse IP régulière de l'hôte - vous ne pouvez contacter cette instance de mongodb que via l'adresse localhost. Et bien sûr, puisque c'est localhost, vous ne pouvez contacter que si à partir d'un client fonctionnant sur le même hôte.

Donc, la façon dont vous le faites maintenant - tunneler une connexion au serveur via ssh puis se connecter à localhost à partir de là - est la façon de le faire.

25
Kenster

J'ai effectué quelques configurations sur ma boîte Ubuntu 18 Vagrant afin de réussir la connexion à distance de MongoDB à l'aide de Robo 3T GUI. Je l'ai expliqué dans les étapes suivantes.

  1. Sur le serveur Ubuntu, pour ouvrir Mongo Shell, exécutez:
    $ mongo
    
  2. Dans mongo Shell, tapez la commande suivante pour créer un nouvel utilisateur administrateur.

    > use admin;
    > db.createUser({user:"admin", pwd:"password", roles:[{ role: "root", db: "admin" }]});
    
  3. Par défaut, mongodb est configuré pour autoriser les connexions uniquement à partir de l'hôte local (IP 127.0.0.1). Nous devons autoriser les connexions à distance depuis n'importe quelle adresse IP. La modification suivante ne doit être effectuée que sur votre serveur de développement. Ouvrez le fichier etc/mongod.conf et effectuez la modification suivante.

    # network interfaces
        net:
            port: 27017
            bindIp: 0.0.0.0   #default value is 127.0.0.1
    

    Toujours dans la même option de sécurité mongod.conf décommenter le fichier et ajouter l'option autorisation comme indiqué ci-dessous.

    security:
        authorization: enabled
    
  4. Enregistrez et quittez le fichier mongod.conf et redémarrez le serveur mongodb.

    $ Sudo servcie mongod restart
    
  5. Téléchargez et installez l'outil graphique Robo 3T.

  6. Sur l'interface graphique de Robo 3T, dans les paramètres de connexion, vous devez effectuer quelques modifications comme indiqué sur les captures d'écran ci-dessous.

enter image description here

Entrez mongodb admin nom d'utilisateur et mot de passe de la base de données que vous avez créé précédemment.

enter image description here

Ici, j'ai entré mes informations d'identification ssh de la boîte Ubuntu 18 Vagrant.

enter image description here

Enregistrez les modifications et appuyez sur l'icône connect pour voir si la connexion fonctionne correctement.

0
Krishna