#Что означает ошибка
FATAL: password authentication failed for user "postgres"
Ошибка «FATAL: password authentication failed for user» означает, что сервер PostgreSQL получил подключение, но отклонил учётные данные. Причины: неверный пароль, пользователя нет, в pg_hba.conf для вашего адреса указан иной метод аутентификации, либо пароль хранится в старом формате md5, а сервер ждёт scram-sha-256.
Проверяйте по порядку: пользователь и пароль, метод в pg_hba.conf, адрес подключения (localhost или внешний), версия клиента.
PostgreSQL выбирает метод проверки (peer, scram-sha-256, md5, trust) по правилам pg_hba.conf. Если метод требует пароль, а пароль неверен, возвращается эта ошибка.
#Причины и решения
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Неверный пароль или имя пользователяОпечатка, старый пароль, другой пользователь. | Ошибка при подключении только с этим пользователем. | Проверьте данные, сбросьте пароль. |
| У пользователя нет пароляРоль создана без пароля, а метод требует его. | Ошибка для новой роли. | Задайте пароль командой ALTER USER. |
Правило в pg_hba.conf не подходитДля вашего адреса указан другой метод (peer, md5). | Локально через сокет работает, по TCP — нет (или наоборот). | Проверьте и исправьте правило, перезагрузите конфигурацию. |
Несовпадение метода шифрования пароляПароль сохранён в md5, клиент старый, а сервер ждёт scram-sha-256. | После обновления PostgreSQL или смены password_encryption. | Задайте пароль заново и обновите клиент. |
#Пошаговое решение
- Проверьте пользователя и парольОшибка
FATAL: password authentication failed for user "имя"означает, что сервер PostgreSQL ответил и отклонил проверку учётных данных. Откройте настройки подключения приложения или pgAdmin: проверьте адрес, порт, имя базы и именно ту роль, под которой оно входит. На сервере с несколькими кластерами можно случайно подключиться не туда. При вводе пароля проверьте раскладку, регистр, пробелы при копировании и хранилище секретов приложения; не публикуйте пароль и не вставляйте его в командную строку или URL, попадающий в историю оболочки. - Задайте новый парольСначала попробуйте отдельное подключение к тому же серверу и базе через pgAdmin («Register Server»/свойства существующего подключения) или
psql -h АДРЕС -p ПОРТ -U ИМЯ -d БАЗА, заменив четыре значения. Введите пароль в появившемся скрытом запросе. Если подключение прошло, сервер и пароль исправны, а проблема может быть в старой записи секрета приложения или другой среде выполнения. Если ошибка повторяется, администратор должен проверить существование роли и настройки авторизации, а не открывать новые сетевые порты. - Найдите pg_hba.confЕсли пароль утрачен, только администратор с разрешённым доступом к кластеру PostgreSQL может изменить его. На Linux при стандартной локальной настройке это часто
sudo -u postgres psql; внутри psql выполните\duдля списка ролей, затем команду\password ИМЯ_РОЛИ, укажите новый сильный пароль по запросу и повторите ввод. Команда\passwordне раскрывает секрет в истории SQL, в отличие отALTER ROLE ... PASSWORD '...'. Если локального доступа нет, не меняйтеpg_hba.confнаtrustи не отключайте аутентификацию: запросите доступ у владельца сервера. - Перечитайте конфигурациюЕсли роль существует и новый пароль всё равно не принимается, администратор из привилегированного psql запускает
SHOW hba_file;и проверяет фактическийpg_hba.conf; правила читаются сверху вниз, первое подходящее определяет метод входа. Посмотрите, требует ли правилоscram-sha-256/другую совместимую схему, и поддерживает ли её клиент. Для диагностики в современных версиях пригодно представлениеpg_hba_file_rules. Изменения согласуйте заранее и сохраните копию конфигурации; не ставьтеtrustи не разрешайте всем адресам доступ к серверу. - Проверьте подключениеЕсли администратор действительно исправил
pg_hba.conf, на Linux необходимо перечитать конфигурацию: из привилегированного psql выполнитеSELECT pg_reload_conf();и проверьте результатt; на Windows новые соединения обычно получают правила сразу. Смена пароля роли сама по себе не требует перезапуска сервера. Повторите подключение из шага 2 и после успеха обновите секрет в приложении или хранилище секретов. Если ошибка осталась, сохраните обезличенный журнал сервера, адрес и роль для администратора, но не прикладывайте пароли. - Не задавайте пароль непосредственно в SQL команде: он попадёт в журнал или историюLinux · Терминал (Bash)С осторожностьюНужен sudoНе задавайте пароль непосредственно в SQL команде: он попадёт в журнал или историю. Требуются права администратора.
# На сервере Linux с разрешённой локальной авторизацией:sudo -u postgres psql# Внутри psql: \du — просмотр ролей; \password ИМЯ_РОЛИ — безопасная интерактивная смена пароля.Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
#Если не помогло
Не ставьте метод trust в pg_hba.conf для сетевых подключений: он разрешает вход без пароля любому с этого адреса. Не храните пароли в репозитории — используйте переменные окружения или менеджер секретов.
#Как работает pg_hba.conf
Файл pg_hba.conf определяет, откуда и каким способом можно подключаться. Правила читаются сверху вниз, применяется первое подходящее. Строка host all all 127.0.0.1/32 scram-sha-256 требует пароль, peer на локальном сокете проверяет имя пользователя ОС. После правки: sudo systemctl reload postgresql.
#Старые клиенты и md5
В PostgreSQL 14+ по умолчанию используется scram-sha-256. Если пароль был задан ранее в md5, пересоздайте его командой ALTER USER имя PASSWORD 'новый'; при password_encryption = scram-sha-256. Старые драйверы без поддержки SCRAM нужно обновить.