FATAL: password authentication failed - jak naprawić

PostgreSQL

FATAL: password authentication failed - jak naprawić

W skrócie

Ten komunikat pojawia się dopiero wtedy, gdy sieć i reguły dostępu są już w porządku - serwer przyjął połączenie i sprawdza hasło. Odrzucenie oznacza, że coś jest nie tak z samym hasłem albo z metodą jego weryfikacji. Problem dotyczy każdego, kto zakłada nowe role bazy albo migruje aplikację między środowiskami. Pokazujemy, jak odróżnić złe hasło od źle dobranej metody uwierzytelniania i jak jedno i drugie naprawić.

Jak to wygląda w praktyce

Połączenie dochodzi do serwera, ale kończy się odmową na etapie hasła:

$ psql -h 127.0.0.1 -U app -d sklep
Password for user app:
psql: error: connection to server at "127.0.0.1", port 5432 failed:
FATAL:  password authentication failed for user "app"

W logu serwera często widać dokładniejszy powód - na przykład, że rola w ogóle nie ma hasła:

FATAL:  password authentication failed for user "app"
DETAIL:  User "app" has no password assigned.
        Connection matched file "/etc/postgresql/16/main/pg_hba.conf" line 96: host all all 127.0.0.1/32 scram-sha-256

Linia Connection matched ... line 96 jest bezcenna - mówi, która reguła i jaka metoda uwierzytelniania zostały użyte. To pierwszy trop, gdy hasło wydaje się poprawne, a serwer i tak odmawia.

Dlaczego tak się dzieje

Po dopasowaniu reguły z pg_hba.conf serwer weryfikuje tożsamość zgodnie z metodą z tej reguły. Przy scram-sha-256 lub md5 porównuje podane hasło z zaszyfrowanym hasłem zapisanym dla roli w katalogu systemowym pg_authid. Odmowa ma zwykle jedną z trzech przyczyn - hasło jest po prostu błędne, rola nie ma ustawionego żadnego hasła (typowe dla świeżo utworzonych ról), albo metoda w regule nie pasuje do formatu hasła w bazie. Ten ostatni przypadek zdarza się po zmianie password_encryption - jeśli hasło zostało zapisane starym algorytmem md5, a reguła wymaga scram-sha-256, weryfikacja się nie powiedzie, dopóki nie ustawisz hasła na nowo. Uwaga na kolejność reguł - jeśli wcześniejszy wiersz w pg_hba.conf przechwytuje połączenie inną metodą, hasło może być sprawdzane inaczej, niż zakładasz.

Jak to rozwiązać krok po kroku

1. Sprawdź w logu serwera linię Connection matched ... line N - powie, która reguła i jaka metoda zostały użyte dla tego połączenia.
2. Ustaw hasło roli na nowo, wykonując polecenie jako administrator: sudo -u postgres psql -c "ALTER ROLE app WITH PASSWORD 'nowe_haslo';".
3. Upewnij się, że nowe hasła zapisują się bezpiecznym algorytmem: SHOW password_encryption; powinno zwrócić scram-sha-256. Jeśli nie, ustaw ten parametr w postgresql.conf.
4. Dopasuj metodę w pg_hba.conf do formatu hasła - dla nowoczesnych haseł wpisz w regule scram-sha-256, a po zmianie algorytmu ustaw hasło jeszcze raz, aby zapisało się w nowym formacie.
5. Przeładuj konfigurację, jeśli zmieniałeś reguły: sudo -u postgres psql -c "SELECT pg_reload_conf();".
6. Sprawdź, że łączysz się właściwą rolą i bazą - literówka w nazwie roli albo pomyłka środowiska (test kontra produkcja) daje identyczny komunikat.

Jak sprawdzić, że zadziałało

Najpierw upewnij się, że rola ma zapisane hasło - kolumna rolpassword nie powinna być pusta:

SELECT rolname, (rolpassword IS NOT NULL) AS ma_haslo
FROM pg_authid
WHERE rolname = 'app';

Następnie zaloguj się nowym hasłem. Aby uniknąć interaktywnego pytania, możesz podać hasło zmienną środowiskową na czas jednego polecenia - poprawne logowanie zwróci wynik:

$ PGPASSWORD='nowe_haslo' psql -h 127.0.0.1 -U app -d sklep -c "SELECT current_user;"

Wróć do listy: 100 najczęstszych pytań i problemów z PostgreSQL

Sprawdź szkolenie: Administracja, replikacja i tuning baz danych PostgreSQL

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Sprawdź szkolenie: Zaawansowana administracja PostgreSQL (HA, DR, monitoring, skalowanie)

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5