Postgres: пользователь не прошел проверку подлинности peer - как исправить

kirilljsx

В PostgreSQL часто возникает ошибка «пользователь не прошел проверку подлинности peer». Это происходит при локальных подключениях, когда сервер требует соответствия системного пользователя и имени в БД. Разберем, почему это случается и как быстро решить проблему без лишних хлопот.

Такая ошибка блокирует доступ к базе, особенно если вы подключаетесь как postgres, но системного пользователя с таким именем нет. Мы пройдем по причинам, найдем файл конфигурации и применим проверенные фиксы. Это сэкономит часы поиска и вернет работу в норму.

Что значит peer authentication в PostgreSQL

Peer authentication — это метод проверки в PostgreSQL, который работает только для локальных подключений через Unix-сокеты. Он проверяет, совпадает ли имя системного пользователя (из ОС) с именем пользователя БД. Если вы запускаете psql -U postgres, а в системе нет пользователя postgres, сервер отвергает подключение с ошибкой «peer authentication failed».

Это защитный механизм по умолчанию в Linux-дистрибутивах вроде Ubuntu. Он удобен для разработки, где имена совпадают, но мешает в продакшене или при установке MIMIC, Docker-контейнерах и CI/CD. Представьте: вы клонируете репозиторий, пытаетесь загрузить данные в БД — и стоп. Типичный пример из GitHub-issues: разработчик не может запустить psql для MIMIC, потому что pg_hba.conf настроен на peer для всех локальных подключений.

Сервер ищет строку local all all peer в конфиге и отказывает, если пользователь не matches. Это не баг, а фича для безопасности — без пароля, но строго по именам. Теперь перейдем к поиску и редактированию файла.

Где искать pg_hba.conf: Запустите sudo find / -type f -name "pg_hba.conf" 2>/dev/null, чтобы найти путь (обычно /etc/postgresql/*/main/pg_hba.conf).
Редактирование: Измените local all all peer на local all all md5 или trust для тестов.
Перезапуск: sudo service postgresql restart или sudo systemctl restart postgresql.

Метод	Преимущества	Риски
peer	Без пароля, безопасно для локалки	Не работает без совпадения имен
md5	Парольная аутентификация	Нужно знать пароль postgres
trust	Полный доступ без проверки	Только для dev, небезопасно

Пошаговое исправление ошибки peer

Сначала убедитесь, что проблема именно в peer: запустите psql без параметров — если войдет под вашим системным именем, то да, дело в несоответствии. В Ubuntu postgres часто не создается как системный юзер при установке через apt, особенно в контейнерах или VM. Поэтому psql -U postgres фейлит.

Решение №1: отредактировать pg_hba.conf. Найдите файл, откройте sudo nano /path/to/pg_hba.conf. Строка # TYPE DATABASE USER ADDRESS METHOD с local all all peer меняется на local all all md5. Сохраните, перезапустите сервис. Теперь psql -U postgres -W запросит пароль — если его нет, создайте через sudo -u postgres psql и ALTER USER postgres PASSWORD 'yourpass';.

Если вы в Docker или CI вроде AppVeyor, peer мешает скриптам вроде createdb. Там фикс — не юзать PGUSER=postgres, а полагаться на текущего юзера или менять conf на лету. В Confluence или Atlassian стеке pg_dump падает по той же причине: хост не имеет pg_hba.conf или он строг.

Создайте системного пользователя: sudo adduser postgres — редко нужно, но решает root-причину.
Подключитесь под своим юзером: psql -d yourdb -U yourlinuxuser вместо postgres.
Автоматизация в скриптах: Добавьте sed -i 's/peer/md5/' pg_hba.conf перед рестартом.

Нюанс: После правок проверьте pg_lsclusters — убедитесь, что кластер на правильном порту и версии.

Альтернативы и продвинутые настройки

Если md5 не подходит, настройте ident или pam — они похожи на peer, но гибче. В pg_hba.conf можно указать local postgres postgres peer для конкретного юзера. Для продакшена комбинируйте: peer для локалки, scram-sha-256 для TCP.

В CI/CD (AppVeyor, GitHub Actions) часто юзают init-скрипты: меняют conf перед стартом postgres сервиса. Пример: в yml добавьте шаг echo 'local all all md5' >> pg_hba.conf. Это решает createdb: FATAL: Peer authentication failed for user "postgres". В MIMIC-code issues рекомендуют именно это + рестарт.

Если база в контейнере, монтируйте volume с измененным conf или юзайте POSTGRES_HOST_AUTH_METHOD=md5 в docker-compose. Для Atlassian/Confluence: проверьте, есть ли pg_hba.conf вообще — иногда bundled Postgres его игнорирует.

scram-sha-256: Современный метод (PostgreSQL 10+), хэширует пароли солиднее md5.
TCP-подключения: Всегда md5 или выше, peer не работает по сети (host all all 127.0.0.1/32 md5).
Логи: /var/log/postgresql/ покажет точную причину отказа.

Сценарий	Рекомендация	Команда
Dev локалка	md5	`local all all md5`
Docker/CI	trust/md5	Init-скрипт с sed
Прод	scram + SSL	`hostssl all all 0.0.0.0/0 scram-sha-256`

Когда peer все-таки стоит оставить

Peer хорош для командной работы: каждый dev подключается под своим Linux-именем без паролей. Но только если все юзеры в БД созданы заранее. В крупных проектах это упрощает деплой — нет нужды хранить пароли в env.

Если ошибка persists после фиксов, проверьте SELinux/AppArmor — они блокируют сокеты. Или версия PostgreSQL: в 14+ peer строже с группами. Подумать стоит над миграцией на роли с GRANTами вместо суперюзера postgres.

Другие аспекты: ротация паролей, аудит логов, миграция на облачные RDS с IAM-аутентификацией. Там peer неактуален, но базовые принципы те же.