PostgreSQL-Fehler: password authentication failed for user

SQLSTATE 28P01 (invalid_password) · Aktualisiert 9. Juli 2026

psql: error: connection to server at "localhost" (127.0.0.1), port 5432 failed: FATAL:  password authentication failed for user "app_user"

Sie haben den Server erreicht, pg_hba.conf wählte für diese Verbindung eine passwortbasierte Authentifizierungsmethode, und die Passwortprüfung schlug fehl. Die Client-Meldung ist bewusst vage; das Server-Log sagt meist mehr.

Was dieser Fehler bedeutet

Dem Client wird nur "authentication failed" mitgeteilt — das ist beabsichtigt, um Angreifern keine Informationen preiszugeben. Das Server-Log hingegen zeichnet den zugrunde liegenden Grund zum selben Zeitpunkt auf: die Rolle hat kein Passwort zugewiesen, das Passwort stimmt nicht überein, oder das gespeicherte Passwortformat ist mit der von pg_hba.conf geforderten Authentifizierungsmethode nicht verwendbar.

Letzteres verdient ein Wort: Passwörter werden gehasht gespeichert, mit dem Algorithmus, den password_encryption hatte, als das Passwort gesetzt wurde (scram-sha-256 auf modernen Versionen, md5 historisch). Das Ändern von password_encryption oder der pg_hba-Methode konvertiert bestehende gespeicherte Passwörter nicht — Mismatches zeigen sich als fehlgeschlagene Logins für Passwörter, die "definitiv richtig" sind.

Häufige Ursachen

• Falsches Passwort oder falscher Benutzer — einschließlich "richtiges Passwort, falsche Umgebung": Staging-Zugangsdaten gegen Produktion, oder ein Docker-Port-Mapping, das auf eine andere Instanz zeigt, als Sie denken.
• Der Rolle ist kein Passwort gesetzt (mit CREATE ROLE erstellt und nie eines vergeben). Jedes Passwort schlägt fehl; nur das Server-Log sagt warum.
• SCRAM/md5-Mismatch: Passwort als md5 gespeichert, während pg_hba scram-sha-256 verlangt, oder eine sehr alte Client-Bibliothek, die kein SCRAM spricht.
• Sonderzeichen in einer Connection-URI (@, :, /, # im Passwort) nicht prozent-kodiert, sodass das geparste Passwort nicht das ist, was Sie eingegeben haben.

So diagnostizieren Sie ihn

• Lesen Sie das Server-Log zum Zeitpunkt des Fehlschlags — es nennt fast immer die eigentliche Ursache.
• Prüfen Sie, welche pg_hba-Regel die Verbindung trifft: SELECT * FROM pg_hba_file_rules; zeigt die geparsten Regeln in Reihenfolge (erste Übereinstimmung gewinnt).
• Testen Sie direkt mit psql und nehmen Sie Anwendung, URI-Parsing und Pooler aus der Gleichung: psql "host=... user=app_user dbname=appdb" und geben Sie das Passwort interaktiv ein.

So beheben Sie ihn

• Setzen Sie das Passwort zurück — bevorzugen Sie psqls \password gegenüber einer schlichten SQL-Anweisung, damit das neue Passwort nicht im Server-Log oder in der Shell-Historie landet:

  \password app_user

• Richten Sie den Stack auf SCRAM aus: setzen Sie password_encryption = 'scram-sha-256', verwenden Sie scram-sha-256 in pg_hba.conf und setzen Sie jedes Passwort neu nach der Änderung, damit die gespeicherten Hashes passen.
• Prozent-kodieren Sie Passwörter in URIs, oder übergeben Sie das Passwort über PGPASSWORD/.pgpass/Verbindungsparameter statt über die URI.