Не могу зайти под новым юзером

На centos 8 стоит postgresql. Я проделываю все действия по созданию роли и бд отсюда. Но, в итоге, после того как пытаюсь зайти под новым юзером, получаю это:

psql: error: could not connect to server: could not initiate GSSAPI security context: Unspecified GSS failure.  Minor code may provide more information
could not initiate GSSAPI security context: Configuration file does not specify default realm
FATAL:  Ident authentication failed for user "username"

Как решить проблему?

Версия postgres: 12.3


Я подразумеваю, что у Вас есть чистая БД и вы заходите в БД, как я описываю здесь.


Ответы (2 шт):

Автор решения: hedgehogues

Скорее всего проблема с аутентификацией. В частности, ряд ссылок выводят на проблему с протоколом kerberos: 1, 2, 3, 4, 5, 6, 7, 8, 9


В комментариях посоветовали обратить внимание на файл pg_hba.conf. У меня в системе он найден в /pgdata/12/data/.


Документацию по этому файлу можно найти здесь: 10, 11, 12


Содержимое файла:

pg_hba.conf

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            ident
# IPv6 local connections:
host    all             all             ::1/128                 ident
# Allow replication connections from localhost, by a user with the
# replication privilege.
local   replication     all                                     peer
host    replication     all             127.0.0.1/32            ident
host    replication     all             ::1/128                 ident

В ссылках 1, 2, 6 приведены логи похожие на те, что указаны в текущем вопросе.


В 7 предлагается посмотреть в лог. Делается предположение, что основная проблема кроется в аутентификации, а не kerberos.

Лог найден по пути: /pgdata/12/data/log. Список файлов:

-rw------- 1 postgres postgres   75 Sep  4 22:47 postgresql-Fri.log
-rw------- 1 postgres postgres    0 Sep  7 00:00 postgresql-Mon.log
-rw------- 1 postgres postgres    0 Sep  5 00:00 postgresql-Sat.log
-rw------- 1 postgres postgres    0 Sep  6 00:00 postgresql-Sun.log
-rw------- 1 postgres postgres    0 Sep  3 00:00 postgresql-Thu.log
-rw------- 1 postgres postgres 3304 Sep  8 17:23 postgresql-Tue.log
-rw------- 1 postgres postgres 7584 Sep  9 16:34 postgresql-Wed.log

Заменил один из файлов на postgresql-Wed-copy.log. Осуществил действия в postgres. Ещё одного файла с логами не появилось. Делаю вывод, что данные логи могут иметь одношение не к текущему postgres, хотя логи очень похожи на мои последние действия.

При внесении операций в БД, в лог ничего не записывается. Есть подозрение, что я зашёл в какую-то не ту директорию.


Исходники могут лежать в разных местах:

  • /usr/local/pgsql/data
  • /var/lib/pgsql/$version
  • /var/lib/postgresql/[version]/data/

У меня, одна из директорий эта: /var/lib/pgsql/$version

Там очень пусто:

total 4
drwx------ 2 postgres postgres   6 Jun 15 02:23 backups
drwx------ 2 postgres postgres   6 Jun 15 02:23 data
-rw------- 1 postgres postgres 906 Jul  8 12:27 initdb.log

Директории пустые. Лог выглядит так:

The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /pgdata/12/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Europe/Moscow
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

Success. You can now start the database server using:

    /usr/pgsql-12/bin/pg_ctl -D /pgdata/12/data -l logfile start


/usr/pgsql-12/bin/pg_ctl -D /pgdata/12/data -l logfile start

Покажет, где лежат данные postgres следующая команда:

ps -ef|grep "postgres.*-D"

Файл с логами, который мы переименовали выше продолжает меняться даже с другим именем. Это странно.


Если зайти

sudo su

то окажется, что часть лога пропадает при попытке залогиниться так:

psql -h localhost vscale_db username

лог:

psql: error: could not connect to server: FATAL:  Ident authentication failed for user "username"
→ Ссылка
Автор решения: Fat-Zer

Если кратко, то происходит примерно следующее:

При psql -h localhost vscale_db username psql пытается подключится к серверу по протоколу tcp на 127.0.0.1.

Сервер видит в своём pg_hba.conf строчку:

host    all             all             127.0.0.1/32            ident

и пытается «аутентифицировать» пользователя по протоколу ident. Для этого на хосте должен быть рабочий ident сервер и имя системного пользователя (см. whoami) от которого запущен psql должно совпадать с именем пользователя БД (username, в данном случае). Если это не удаётся, то идёт отказ авторизации.

Что делать:

Чтобы включить авторизацию по паролю нужно просто поменять auth-метод, например чтобы разрешить пользователю username подключаться к БД vscale_db и при этом у него запрашивался пароль в pg_hba.conf нужно добавить строчки (желательно в начало):

local   all             username                                md5
host    all             username        127.0.0.1/32            md5
host    all             username        ::1/128                 md5

При этом пароль при передаче будет шифроваться с помощью md5. Но для локальных подключениях это не к чему, так что вместо этого можно использовать password.

Чтобы все пользователи с localhost'а по паролю можно соответственно заменить ident на password в записях, которые уже есть в файле:

host    all             all             127.0.0.1/32            password
host    all             all             ::1/128                 password

Чтобы пароль не спрашивался вовсе можно использовать trust.

После правки конфига также надо не забыть сказать postgres, чтобы он перезагрузил настройки из файла, на systemd-системе это можно сделать как-то так:

systemctl reload postgresql-12

Полноценный перезапуск (restart) СУБД не обязателен.


Подробности см. в документации.

→ Ссылка