Эта проблема блокирует доступ к postgres, но решается за минуты. В статье разберём, почему она появляется, и покажем проверенные способы её устранить. Вы узнаете, как быстро войти в БД и настроить безопасный доступ без риска для системы.

Почему возникает peer authentication

Peer authentication в PostgreSQL проверяет, совпадает ли имя системного пользователя (из Linux) с именем пользователя БД. Если вы запускаете psql -U postgres, но в системе нет пользователя postgres или вы вошли под другим аккаунтом - подключение блокируётся. Это стандартный механизм безопасности для локальных соединений по Unix-сокетам.

Например, вы установили PostgreSQL через apt на Ubuntu, но пытаетесь подключиться как обычный разработчик. Система требует точного совпадения: postgres в Linux = postgres в БД. Без этого psql выдаёт fatal error и закрывается. Такой подход защищает от несанкционированного доступа, но мешает в повседневной работе.

А теперь посмотрим, где искать корень проблемы:

• pg_hba.conf управляет правилами аутентификации. Строка local all all peer требует совпадения пользователей.
• Системный пользователь postgres создаётся при установке, но не всегда активен для вашего аккаунта.
• Unix-сокеты используются по умолчанию для local подключений - они быстрее TCP, но строже по правилам.

Быстрые способы подключения без редактирования конфигов

Иногда не хочется лезть в pg_hba.conf, особенно если сервер общий. Есть простые обходные пути, которые работают сразу. Они используют системные фичи Linux и не требуют перезапуска PostgreSQL.

Первый вариант - переключиться на системного пользователя postgres. Команда sudo -i -u postgres psql запускает psql от имени нужного юзера. Это идеально для разового доступа или скриптов. После входа вы окажетесь в консоли БД без вопросов о пароле.

Второй подход - подключение через TCP вместо сокетов. Укажите -h 127.0.0.1 или -h localhost, и peer-аутентификация отключится в пользу host-based правил. Это полезно, если в pg_hba.conf есть строка для 127.0.0.1 с md5.

Вот основные команды для быстрого старта:

• sudo -u postgres psql - вход под системным postgres
• psql -U postgres -h 127.0.0.1 - TCP-подключение локально
• sudo -i -u postgres createdb mydb - создание БД от postgres

Важно: После таких подключений всегда выходите командой \q, чтобы не висеть в сессии.

Настройка pg_hba.conf для постоянного доступа

Файл pg_hba.conf - сердце аутентификации PostgreSQL. Он лежит обычно в /etc/postgresql/<версия>/main/ или /var/lib/pgsql/data/. Найдите строку local all all peer и замените метод на md5 или scram-sha-256 для парольного доступа.

Редактирование шаг за шагом: откройте файл sudo nano /etc/postgresql/14/main/pg_hba.conf. Измените peer на md5. Сохраните, перезапустите сервис sudo systemctl restart postgresql. Теперь psql спросит пароль вместо проверки пользователя.

Если нужно временно открыть доступ, используйте trust - но только для теста! После настройки пароля верните md5. Пример полной последовательности:

1. Добавьте local all postgres trust в pg_hba.conf
2. sudo systemctl restart postgresql
3. psql -U postgres
4. ALTER USER postgres PASSWORD 'mypassword';
5. Верните md5 и перезапустите снова

Установка пароля и безопасность на будущее

После входа в БД обязательно задайте пароль суперюзеру. Команда ALTER USER postgres WITH PASSWORD 'strongpass'; создаст md5-хэш. Теперь подключение по паролю будет работать везде - из приложений, pgAdmin или удалённо.

Проверьте роли: \du покажет всех пользователей. Добавьте новых через CREATE USER myuser WITH PASSWORD 'pass';. Для продакшена настройте отдельные БД и роли вместо all-доступа. Не забудьте права на сокеты: chown postgres:postgres /var/run/postgresql/.

Ключевые шаги для безопасной настройки:

• Ограничьте local all только нужными пользователями
• Используйте scram-sha-256 вместо md5 в новых версиях
• Логируйте подключения: log_connections = on в postgresql.conf

Когда проблема глубже - продвинутые кейсы

Иногда ошибка маскирует другие беды: нет сокета, SELinux блокирует или Docker-контейнер. Проверьте статус systemctl status postgresql и логи /var/log/postgresql/. Если pg_hba.conf не найден - найдите через sudo find / -name pg_hba.conf.

В CI/CD вроде AppVeyor или GitHub Actions peer сбивается из-за пользователя appveyor. Автоматизируйте sudo -u postgres или редактирование conf в init-скрипте. Для Confluence или других приложений убедитесь, что DB-владелец совпадает с системным.

Типичные ловушки:

• Версия PG: в 15+ scram по умолчанию
• Путь к файлу отличается в Docker: /var/lib/postgresql/data/
• Ownership: sudo chown -R postgres:postgres /var/lib/postgresql/

Итоги по peer authentication в двух словах

Ошибка peer authentication failed решается сменой пользователя, TCP или pg_hba.conf. Основное - поймите разницу между local/peer и host/md5. После настройки протестируйте все сценарии: psql, pg_dump, приложения.

Осталось место для тонкой настройки: репликация, SSL, внешние подключения. Если копать глубже - смотрите документацию по ролям и кластерам, там ещё больше нюансов для крупных проектов.