Anmeldung von anderem System - Auth schlägt fehl

Hey zusammen,
so langsam komme ich an meine Grenzen.
Ich habe eine Postgresql Datenbank (12) aufgebaut und eine Datenbank angelegt mit User / Rolle.
Nun möchte ich mich von dem lokalen System (oder einem anderen) damit verbinden:
psql -h -p 5433 -U postgres

Wenn ich in der PG_HBA die Anmeldung aus dem Netz auf “Trust” setze klappt es, klar, wird ja auch einfach durchgewunken. Finde ich nur eher unsicher.
Sobald ich aber MD5, Password oder sonstige Parameter einstelle (DB immer neu gestartet) kommt noch der Login-Prompt und danach die Meldung "psql: error: FATAL: password authentication failed for user "
Ich habe das Kennwort nun auf vier Zeichen geändert, sowohl in der Datenbank mit alter Befehl als auch im OS bei dem entsprechenden User. Diese sind also alle gleich.
Dennoch kommt immer wieder die Meldung… Das kann doch nicht sein? Wo liegt mein Fehler?

Google sagt Trust einfach lassen, das halte ich jedoch unter Sicherheitsaspekten für nicht wirklich schön… Kenne ich auch so von keiner Datebank. Also, was mache ich falsch?

Habt vielen Dank.

Gruß

Du brauchst bur den DB-User Passwort zu setzen, und Du mußt den korrekten Eintrag in der pg_hba.conf ändern, dann klappt das auch. Was hast Du denn genau gemacht?

Hey,
hab vielen Dank für deine Antwort.
Das Kennwort des Users habe ich mir folgendem Befehl gesetzt:
alter user postgres with password ‘Test’;

Der entsprechende Eintrag meiner pg_hba.conf sieht wie folgt aus:
host all all /26 trust

Damit klappt es (halt keine Autorisierung). Ändere ich diesen ab ist es sofort vorbei…

Gruß

Nun ja, /26 ist keine valide CIDR-Adresse, und trust - vertraut halt. Ändere das mal auf 0.0.0.0/0 z.B. oder halt korrekte CIDR für Dein Netz. Eine Änderung der pg_hba.conf wird auch durch simples reload übernommen, Restart nicht nötig.

Sorry, da hat er was weg geschnitten…
So sieht es aus:
host all all IP-Adresse des Netzes/26 trust

Also ja, die CIDR ist korrekt gesetzt. Ich könnte höchstens mal 0.0.0.0 testen…

Also der Wechsel auf die Zeile:
host all all 0.0.0.0/26 trust

bringt generell folgenden Fehler:
psql: error: FATAL: password authentication failed for user “postgres”

Er fragt nun das Kennwort ab (warum auch immer) checkt es jedoch scheinbar erneut nicht korrekt gegen.
Der Aufruf war:
psql -h -p 5433 -U postgres

  • Reihenfolge der Einträge stimmt?
  • Du hast Port 5433, Default ist 5432, hast Du vielleicht 2 Instanzen und da was verdreht?

Ich hab die Datei mal umgestellt, da ich ehrlicherweise richtig oder falsch mangels Wissen nicht differenzieren könnte.
Sie beginnt nun so:

Database administrative login by Unix domain socket

local all postgres md5

TYPE DATABASE USER ADDRESS METHOD

“local” is for Unix domain socket connections only

local all all md5

IPv4 local connections:

host all all 0.0.0.0/26 trust

Nee, ich hab auf 5433 gewechselt, da die Anwendung dies so braucht.
Auf 5432 läuft nichts, soeben noch geprüft.

0.0.0.0 scheint da auch nicht gut zu sein:
psql: error: FATAL: no pg_hba.conf entry for host “10.128.1.89”, user “mqttauth”, database “mqttauth”, SSL off
Wenn ich das Netz wieder eintrage klappt es wenigstens bis zum falschen Kennwort wieder.

Ich habe nun mal einen konkreten Eintrag als erstes gesetzt, also die IP und nicht das Netz.
Dazu dann die Option “password”. Wird abgefragt und es kommt der gleiche Fehler, dass es nicht gültig sei…

tja, wenn PG sagt, das Passwot stimme nicht, dann wird es wohl so sein …

Okay, nehmen wir mal an, es wäre so.
Wie setze ich es korrekt? Ist der oben genannte Befehl in einer PSQL Umgebung nicht hinreichend?
Oder wie kann ich den Part ggf. nochmal machen zur Sicherheit?
Ich nehme bislang immer Test (ohne Anführungszeichen bei der Eingabe). Richtig?

du widersprichst Dir selber. Ohne ’ sollte ein Syntacfehler kommen.

War unglücklich ausgedrückt, entschuldige.
Im Befehl (alter user…) ist es mit ’
Wenn ich hingegen in PSQL nach einem Kennwort gefragt werde gebe ich “nur” Test ein.
So rum ist es richtig.

Dieses Thema wurde automatisch 60 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Antworten mehr erlaubt.