Benutzer-Passwort ändern

Variante 1 — \password (empfohlen)

In psql, für die eigene Rolle (psql nimmt automatisch den aktuell eingeloggten User):

myapp=> \password
Enter new password for user "alice":
Enter it again:

Oder als Admin für eine andere Rolle:

myapp=# \password bob
Enter new password for user "bob":
Enter it again:

Was hier passiert:

1. psql fragt das neue Passwort interaktiv ab — es taucht nicht im Eingabe-Buffer auf.
2. psql hasht das Passwort lokal mit dem aktuellen Verfahren (scram-sha-256 ab PG 14).
3. Es sendet nur den Hash an den Server — niemals Klartext.

Damit landet das Passwort weder im Shell-History, noch im Server-Log, noch in pg_stat_statements. Das ist die einzig richtige Variante für Produktion.

Variante 2 — ALTER ROLE mit Klartext (vorsichtig!)

ALTER ROLE bob WITH PASSWORD 'newpass123';

Was du wissen musst:

• Wenn log_statement = 'ddl' oder 'all' gesetzt ist, landet 'newpass123' als Klartext im Server-Log.
• pg_stat_statements normalisiert das Statement, kann aber Konstanten enthalten — je nach Konfiguration.
• Bei psql -c "ALTER ROLE bob WITH PASSWORD 'newpass123'" landet das Passwort zusätzlich im Shell-History.

Diese Variante ist nur sicher, wenn:

• du das Server-Log explizit nicht auf ddl/all stehen hast, und
• du nicht über die Shell-CLI arbeitest.

In der Praxis: nur für Bootstrap-Skripte (Setup, Tests, CI) — und dort lieber Variante 3.

Variante 3 — ALTER ROLE mit vorgehashtem Passwort

Wenn du ALTER ROLE brauchst (z. B. in einer Migration oder einem Bootstrap-Skript), aber kein Klartext-Passwort verschicken willst:

# Mit psql lokal — kein Server beteiligt:
echo "SELECT pg_catalog.scram_sha_256_hash('newpass123', 'bob');" | psql

Oder pragmatisch: einmal mit \password setzen, dann den Hash aus pg_authid (Superuser-only) auslesen und in das Bootstrap-Skript übernehmen:

SELECT rolpassword FROM pg_authid WHERE rolname = 'bob';
--  rolpassword
-- ---------------------------------------------------
--  SCRAM-SHA-256$4096:abc...$xyz...:lmn...

-- Den Hash kannst du dann verwenden:
ALTER ROLE bob WITH PASSWORD 'SCRAM-SHA-256$4096:abc...$xyz...:lmn...';

Postgres erkennt den SCRAM-SHA-256$…-String und übernimmt ihn als bereits gehashtes Passwort — das Klartext kommt nirgendwo vor.

Anwendungs-Seite: .pgpass

Damit Anwendungen oder Skripte das Passwort nicht jedes Mal interaktiv eingeben müssen, gibt es die Datei ~/.pgpass:

# hostname:port:database:username:password
localhost:5432:myapp:app_user:secret123
db.example.com:5432:*:reporting:reporting_pass

Permissions sind Pflicht — Postgres weigert sich sonst:

chmod 600 ~/.pgpass

Damit kann psql -h db.example.com -U reporting -d analytics ohne Passwortabfrage laufen.

Alternativen für Production-Setups:

• PGPASSWORD-Umgebungsvariable — funktioniert, aber landet in ps-Listen sichtbar. Nicht empfohlen.
• Connection-Service-Datei (~/.pg_service.conf) — strukturierte Connection-Profile.
• Secret-Manager (Vault, AWS Secrets Manager, Doppler, …) — die App holt das Passwort beim Start ab. Standard für Produktion.

Passwort deaktivieren

Wer einer Rolle die Passwort-Authentifizierung entziehen will (etwa weil der User nur noch per Cert oder peer reinkommen darf):

ALTER ROLE bob WITH PASSWORD NULL;

Anmeldungen mit Passwort schlagen ab sofort fehl — andere Auth-Methoden (peer, ident, cert, ldap) gehen weiter.

Mit Ablaufdatum:

ALTER ROLE bob VALID UNTIL '2027-01-01';

Nach dem Datum scheitert die passwortbasierte Anmeldung.

Weiterführende Ressourcen

Externe Quellen

• psql – \password documentation
• ALTER ROLE – PostgreSQL Documentation
• The Password File (.pgpass)
• Password Authentication
• Connection Service File

Verwandte Artikel

• Benutzer und Datenbank erstellen
• Rollen-Attribute
• PostgreSQL unter Ubuntu installieren
• Konfigurationsdateien