PostgreSQL: peer authentication failed for user postgres — как исправить ошибку

kirilljsx

Ошибка peer authentication failed for user postgres в PostgreSQL возникает часто при первом подключении к базе. Это значит, что сервер не пускает пользователя из-за настроек аутентификации. В этой статье разберём, почему так происходит и как быстро решить проблему пошагово.

Знание этих шагов сэкономит часы на отладку. Подходит для новичков и опытных админов. Мы пройдём от диагностики до безопасной настройки без риска для данных.

Что такое peer authentication и почему она ломается

Peer authentication — это метод проверки в PostgreSQL, где доступ даётся только если имя ОС-пользователя совпадает с именем БД-пользователя. По умолчанию для локальных подключений стоит именно peer, что удобно для системных задач, но мешает при подключении под root или другим юзером. Представьте: вы запускаете psql -U postgres, а сервер отвечает отказом, потому что ваш текущий юзер — не postgres.

Проблема типична на свежих установках Ubuntu или Debian. Файл pg_hba.conf управляет этим: там строки вроде local all all peer блокируют несоответствия. Без прав на редактирование сервера подключиться не выйдет. Логично сначала проверить логи PostgreSQL командой sudo tail -f /var/log/postgresql/postgresql-*-main.log, чтобы увидеть точную причину отказа.

Вот распространённые сценарии:

Подключение под root без sudo -u postgres.
Отсутствует UNIX-юзер postgres в системе.
Изменённые права после обновления ОС.

Сценарий	Причина	Быстрое действие
`psql -U postgres`	Нет юзера postgres в ОС	`sudo -u postgres psql`
Локальное подключение	peer в pg_hba.conf	Изменить на md5
После апдейта	Сброс конфига	Перезапустить сервис

Пошаговое решение через pg_hba.conf

Самый надёжный способ — временно переключить аутентификацию на trust или md5, чтобы войти и создать пароль. Файл pg_hba.conf обычно лежит в /etc/postgresql/*/main/. Откройте его с sudo: sudo nano /etc/postgresql/14/main/pg_hba.conf (версия зависит от вашей установки).

Найдите строку local all postgres peer и замените на local all postgres trust. Это отключит пароль на время. Сохраните и перезапустите: sudo systemctl restart postgresql. Теперь psql -U postgres сработает без вопросов.

Дальше в консоли postgres=# выполните ALTER USER postgres PASSWORD 'your_secure_password';. Вернитесь в pg_hba.conf, смените trust на md5 и снова перезапустите сервис. Теперь подключение требует пароль, что безопаснее.

Шаги в деталях:

Редактируйте pg_hba.conf: sudo nano /etc/postgresql/*/main/pg_hba.conf.
Добавьте/измените: local all postgres trust в начало файла.
Перезапуск: sudo systemctl restart postgresql или sudo service postgresql restart.
Подключитесь: psql -U postgres.
Установите пароль: ALTER USER postgres WITH PASSWORD 'mypassword';.
Верните md5: Измените строку обратно и перезапустите.

Важно: trust подходит только для локального доступа; для продакшена используйте scram-sha-256.

Альтернативы без редактирования конфига

Если нет прав на pg_hba.conf, используйте системного юзера. Создайте его: sudo adduser postgres (если отсутствует). Или подключайтесь через sudo -u postgres psql — это обходит peer, имитируя нужного юзера.

Для Docker или облачных инстансов проверьте переменные окружения: PGUSER и PGPASSWORD. В CI/CD вроде AppVeyor ошибка уходит удалением этих переменных, если сервер настроен на passwordless для текущего юзера. В Confluence или других пакетах проблема в коллациях или отсутствующих ролях — проверьте \l в psql.

Варианты подключения:

sudo -u postgres createuser --interactive --pwprompt для новых юзеров.
psql -h localhost -U postgres -W с паролем по TCP.
Изменить в postgresql.conf listen_addresses = '*' для удалённого доступа.

Метод	Плюсы	Минусы
sudo -u postgres	Без прав на конфиг	Только локально
md5 в pg_hba	Парольная защита	Нужно рестарт
scram-sha-256	Современный хэш	PostgreSQL 10+

Методы аутентификации: что выбрать

PostgreSQL поддерживает несколько методов: peer (по ОС-юзеру), md5 (пароль с хэшем), scram-sha-256 (улучшенный), trust (без проверки). Peer хорош для dev, но в проде опасен. Md5 устаревает, переходите на scram.

В pg_hba.conf строки читаются сверху вниз — первая подходящая применяется. Добавляйте специфичные правила: local mydb myuser md5. Для всех: host all all 127.0.0.1/32 md5. После правок всегда рестарт.

Peer: local all all peer — быстро, но небезопасно.
Md5: local all all md5 — пароль обязателен.
Trust: Только для тестов, local all all trust.
Тестируйте: pg_ctl reload вместо полного рестарта.

Метод	Безопасность	Сложность
peer	Низкая	Лёгкая
md5	Средняя	Средняя
scram	Высокая	Средняя

Безопасная настройка после фикса

После решения подумайте о ролях: создайте отдельного юзера CREATE ROLE appuser WITH LOGIN PASSWORD 'pass'. Отзовите суперюзер у postgres: ALTER ROLE postgres NOSUPERUSER. Ограничьте доступ в pg_hba: local appdb appuser md5.

Логи и мониторинг помогут: включите log_connections = on в postgresql.conf. Для кластеров используйте pgbouncer. Осталось учесть SSL для удалёнки и ротацию паролей — это следующий уровень защиты.

Мы разобрали базовые случаи, но в продакшене тестируйте на staging. Теперь ошибка не застанет врасплох.