localhost Verbindung ohne UDP

[mxm]

Hallo,

bisher habe ich mich immer per ident-map bei meinem System authentifiziert.
Nun will ich mich aus dem lokalen Netzwerk verbinden können. In der pg_hba.conf ist dort ein md5 Passwort gefordert.

Also neuer Benutzer:

CREATE USER meinuser PASSWORD 'md5+meinverschlüsseltespasswort';

(ohne das plus)

Wenn ich jetzt also mit dem Rechner eine Verbindung herstellen soll, muss ich verhindern dass er die UDP Sockets anspricht.

Wie geht das?

psql -h 127.0.0.1 -U meinuser

klappt nicht. Passwort wird zwar abgefragt, aber nicht akzeptiert. Ich kann aber ausschließen, dass es sich um das falsche Passwort handelt. Hat jemand eine Idee woran es liegt? Ist das Muster des Passwortes falsch, ich habe gelesen man müsste md5 voranstellen.

Grüße,
mxm

[ads]

Ich weiß zwar nicht genau, was du da planst, aber du machst eine Menge falsch.

Zuerst einmal lauscht PostgreSQL nur auf dem TCP Port, nicht auf dem UDP Port.

Zum zweiten, wenn du dein Passwort bereits verschlüsselt angeben willst, musst du den MD5 String dafür angeben, siehe:

PostgreSQL: Documentation: Manuals: PostgreSQL 8.3: CREATE ROLE

Nichts mit ‘md5…’, das Schlüsselwort ist ENCRYPTED.

[mxm]

ok das ist doch schon mal sehr hilfreich, hatte ich aber aus einem Buch.

Was ich plane: Ich will einfach nur statt über Identmap über die TCP Sockets den Benutzer anmelden und das in dem Fall trotzdem vom gleichen Rechner aus.

…? wieso ne Menge falsch. Die UDP-Sockets sind doch die Dinger für die interne Kommonikation und werden also bei der ident map benutzt (bringe ich da was durcheinander?..eigentlich auch egal)

[ads]

Nun ja, die heißen meines Wissens nicht UDP[/].

UDP ist ein Netzwerkprotokoll.


Wenn du psql mit der Option -h startest, baust du eine Netzwerkverbindung und keine Verbindung über den Unix-Domain-Socket auf.

[mxm]

schade, klappt aber trotzdem nicht

ALTER ROLE WITH ENCRYPTED PASSWORD ‘dasverschlüsseltepw’;


Ist denn
psql -h 127.0.0.1 -U überhaupt richtig um die interne Kommunikation zu umgehen?

[akretschmer]

@mxm

schade, klappt aber trotzdem nicht

ALTER ROLE WITH ENCRYPTED PASSWORD ‘dasverschlüsseltepw’;


Ist denn
psql -h 127.0.0.1 -U überhaupt richtig um die interne Kommunikation zu umgehen?

versuch es mal mit der extra-Option -p , also 5432.

Andreas, müde.

[mxm]

psql -U app -h 127.0.0.1
Passwort für Benutzer app:
psql: FATAL:  Passwort-Authentifizierung für Benutzer »app« fehlgeschlagen

Nein klappt weder mit port noch ohne,

aber eigentlich stimmt die Verbindung glaube ich auch eher, sieht eher aus als wenn das Passwort nicht akzeptiert wird

[ads]

Was steht in deiner pg_hba.conf?

Und wie gesagt, mit “-h” gehst du über das Netzwerk, nicht über den Unix Domain Socket.

[mxm]

Ja genau das will ich auch, also ohne UDP-Sockets über das locale Netzwerk.

Kann die pg_hba.conf leider nicht selbst einsehen, aber eigentlich wurde da eingestellt, dass sich alle Benutzer auf allen Datenbanken per md5 authentifizieren können.


Kann es vllt auch an dem Zeichensatz der Konsole (UTF8 ) liegen? Weiß jemand wie man herausfinden kann, welcher Zeichensatz auf dem Server eingestellt ist?

[ads]

Das liegt nicht am Zeichensatz und den kannst du herausfinden - wenn du mit der Datenbank verbunden bist.


Also, ohne den Eintrag / die Einträge in der pg_hba.conf ist das hier bloß ein großes Rätselraten.

[mxm]

Es scheint sich tatsächlich nur um ein Passwort Problem zu handeln


Denn folgendes habe ich jetzt herausgefunden:

ALTER USER app PASSWORD ‘testpasswort’;


In diesem Falle gebe ich es unverschlüsselt an,

Mache ich selbst im Netz die md5 Verschlüsselung so kommt was anderes heraus, als in der pg_authid unter dieser Rolle steht.
Wie kann das sein? Ich mache meine Einstellungen über Putty , kann es doch irgendwie sein dass meine Zeichen anders interpretiert werden?

[mxm]

Bin mir fast sicher das es daran liegt, mein System erkennt noch nicht mal den richtigen Usernamen:

Konsole:

psql -U app templategis
psql: FATAL:  Ident-Authentifizierung für Benutzer »app« fehlgeschlagen

UPDATE:

Bin jetzt mit pgAdminIII auf der Datenbank mit dem User verbunden.

[akretschmer]

@mxm

Es scheint sich tatsächlich nur um ein Passwort Problem zu handeln


Denn folgendes habe ich jetzt herausgefunden:

ALTER USER app PASSWORD ‘testpasswort’;


In diesem Falle gebe ich es unverschlüsselt an,

Mache ich selbst im Netz die md5 Verschlüsselung so kommt was anderes heraus, als in der pg_authid unter dieser Rolle steht.
Wie kann das sein? Ich mache meine Einstellungen über Putty , kann es doch irgendwie sein dass meine Zeichen anders interpretiert werden?

Du sollst nicht selbst mit md5() spielen, das ist nicht nötig.

Andreas

[akretschmer]

@mxm

Bin mir fast sicher das es daran liegt, mein System erkennt noch nicht mal den richtigen Usernamen:

Konsole:

psql -U app templategis
psql: FATAL:  Ident-Authentifizierung für Benutzer »app« fehlgeschlagen

UPDATE:

Bin jetzt mit pgAdminIII auf der Datenbank mit dem User verbunden.

Du sollst Dich mit der pg_hba.conf beschätigen, ich wiederhole das nochmals mit dem Hinweis auf die Doku dazu: PostgreSQL: Documentation: Manuals: PostgreSQL 8.3: Client Authentication

Andreas

[mxm]

Danke für eure Hilfe, aber wie ich befürchtete lag es nicht an der pg_hba.conf
Allerdings auch nicht an den Zeichensätzen.

Das Problem war: Mit der Option -h 127.0.0.1 verbindet man sich trotzdem noch per UDP socket und nicht wie gewünscht über TCP. Es hat funktioniert als ich -h eingegeben habe.

[akretschmer]

@mxm

Danke für eure Hilfe, aber wie ich befürchtete lag es nicht an der pg_hba.conf
Allerdings auch nicht an den Zeichensätzen.

Das Problem war: Mit der Option -h 127.0.0.1 verbindet man sich trotzdem noch per UDP socket und nicht wie gewünscht über TCP. Es hat funktioniert als ich -h eingegeben habe.

Diese Beobachtung wäre korrekt wenn Du das UDP gegen UNIX tauschen würdest. Im übrigen kann man das auch mittels -p 5432 erreichen. Auf localhost wird Unix-Socket halt bevorzugt, weil es schneller ist.

Andreas

[mxm]

Oh stimmt, die Dinger heißen Unix Sockets.

Sry, sowas macht die Verständigung hier natürlich ziemlich schwierig.