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

Что такое 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 в системе.
• Изменённые права после обновления ОС.

Пошаговое решение через 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 и снова перезапустите сервис. Теперь подключение требует пароль, что безопаснее.

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

1. Редактируйте pg_hba.conf: sudo nano /etc/postgresql/*/main/pg_hba.conf.
2. Добавьте/измените: local all postgres trust в начало файла.
3. Перезапуск: sudo systemctl restart postgresql или sudo service postgresql restart.
4. Подключитесь: psql -U postgres.
5. Установите пароль: ALTER USER postgres WITH PASSWORD 'mypassword';.
6. Верните 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 = '*' для удалённого доступа.

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

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 вместо полного рестарта.

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

После решения подумайте о ролях: создайте отдельного юзера 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. Теперь ошибка не застанет врасплох.