2015-06-27 7 views
5

Ich habe eine Bitnami MEAN-Instanz auf EC2 ausgeführt. Nach langem Finnen konnte ich mich mit der lokalen Shell erfolgreich mit der DB verbinden. Ich habe authentifizierte Benutzer mit allen Berechtigungen erstellt, die für den Zugriff auf die Daten erforderlich sind, und wenn ich den untenstehenden Code ausführe, kann ich ohne Probleme auf die Datenbank zugreifen.Mongo "Authentifizierung fehlgeschlagen" Nur für Remote-Verbindungen. Local Works in Ordnung

sudo mongo admin -u <USERNAME-p <PASSWORD> 

Das heißt, wenn ich versuche, dies zu wiederholen, um eine Remote-Verbindung mit ich wiederholt eine gegebene bin „Auth fehlgeschlagen“ Fehler von MongoDB.

mongo <HOST>:<PORT>/<DATABASE> -u <USERNAME> -p <PASSWORD> 

...

Das ist seltsam, weil ich genau die gleichen Anmeldeinformationen bin mit, wie ich den lokal Shell in Laufen tun. Der einzige Unterschied ist, dass ich die Host- und Portinformationen einfüge. Ich habe auch bestätigt, dass meine Remote-Verbindung funktioniert, wenn ich den Auth-Parameter in mongodb.config deaktivieren.

mongo <HOST>:<PORT>/<DATABASE> 

Offensichtlich in der Produktion möchte ich authentifizieren können. Hat jemand von Ihnen Vorschläge, warum eine Diskrepanz zwischen Remote- und lokaler Authentifizierung besteht?

Antwort

23

Ich war mit dem gleichen Problem konfrontiert.

Das Problem für mich:

Meine lokalen war Mongo Mantel v2.6.10. Es verwendet eine Authentifizierungsmethode namens MONGODB-CR that has been deprecated.

Meine Serverversion ist v3.0.4. Es verwendet eine Authentifizierungsmethode namens SCRAM-SHA-1.

Versuchen Sie lokale Shell und Remote-Server-Versionen mit überprüfen:

mongo --version 
mongod --version 

Wenn sie unterschiedlich sind, aktualisieren Sie Ihre lokale Shell zu v3. (Ich musste es wieder deinstallieren und installieren.)

+2

Danke! Ich hatte vergessen, dass ich darüber geschrieben habe. Aber das war in der Tat das Problem. Ich bin froh, dass ich nicht der Einzige bin, der damit aufgelegt wurde. –

+0

Sie haben meine Stunden gerettet –

0

Dies ist hauptsächlich aus Sicherheitsgründen.

Wenn Sie Zugriff auf die lokale Umgebung haben, ist es leicht anzunehmen, dass Sie ein Administrator des Systems oder eines Entwicklers sind, da Sie Zugriff auf die Maschine selbst haben.

Wenn Sie keinen Zugriff auf den lokalen Computer haben, können Sie dies nicht garantieren, und da eine Datenbanksicherheit (in den meisten Fällen) sehr wichtig ist, ist es sinnvoll, den Remotezugriff nicht zu aktivieren. Sie können dies natürlich deaktivieren, aber es wird nicht empfohlen.

Ich hoffe, ich half.

+0

Wie würde ich dann den Fernzugriff aktivieren? –

+0

Es ist im Wiki dokumentiert (es ist nur notwendig, um die Bindungsadresse zu 0.0.0.0 zu ändern): https://wiki.bitnami.com/Components/mongoDB#section_6 – marcosbc

+0

Yeah. Versuchte das. Es behandelt nicht das Auth-Problem. Durch die Änderung der Bindungsadresse konnte ich nur dann auf den Remote-Mongehost zugreifen, wenn ich den Auth-Parameter in mongodb.config vollständig deaktiviert habe. Aber das Problem in Bezug auf Remotezugriff wurde nicht behandelt. –

0

Installieren Sie die gleiche Version sowohl auf dem Server und auf dem Client löste das Problem für mich. Wie bei @Alexandre oben erklärt, ist es wahrscheinlich ein Problem der Passwortverschlüsselung. MongoDB Version 3.2.7

Ich habe versucht, erfolgreich mit den beiden Methoden:

mongo --host "your_host" --port "your_port" --username "your_user" --password "your_pass" --authenticationDatabase "your_admin_db" 

mongo "your_host:your_port/your_db" --username "your_user" --password "your_pass" --authenticationDatabase "your_admin_db" 

Außerdem stellen Sie sicher, dass Ihr Server für Remote-Zugriffe verfügbar ist. Siehe Details über das Netz.bindip bei https://docs.mongodb.com/v3.2/reference/configuration-options/

1

hatte ich vorher MongoDB Version 3.2.12 wird die Installation und war in der Lage zu einer Remote-Instanz verbinden mit:

mongo -u ‘<USERNAME>’ -p ‘<PASSWORD>’ --host <REPLICA_SET>/<HOST>:<PORT> admin 

Ich bin einen neuen Cluster mit Version 3.4.2 zu schaffen und war nicht in der Lage mit dem gleichen Befehl verbinden. Nachdem ich viele verschiedene Optionen ausprobiert hatte, konnte ich endlich herausfinden, dass ich --authenticationDatabase vor der Admin-Datenbank hinzufügen musste.

0

Nur für den Fall, dass jemand auf dasselbe Problem stoßen sollte, ist die authenticationDatabase nur erforderlich, wenn Sie den Benutzer in einer ANOTHER-Datenbank erstellt haben. Wenn Sie den Benutzer in der Datenbank erstellen, mit der Sie eine Verbindung herstellen, treten keine Probleme auf.

Also Vorsicht: Benutze dann Benutzer erstellen.

Wenn Sie Ihren Benutzer in der Admin-Datenbank erstellen, dann ja, Sie benötigen das AuthenticationDatabase Flag.