Неизвестная причина сбоя аутентификации пароля postgres

Я не могу войти в систему и использовать созданную базу данных, потому что я получаю пароль или ошибку аутентификации однорангового узла. Ниже описывается, как я все настраивал, как я пытался исправить обнаруженные проблемы, а также дополнительная потенциально важная информация.

Я использую postgresql-9.5, и когда я загружал postgres, он был с другим пользователем / именем пользователя linux mint, чем я сейчас пытаюсь получить к нему доступ. Все приведенные ниже команды были отправлены от нового пользователя / имени пользователя.

Я создал новую базу данных postgres и нового пользователя с паролем с помощью следующих команд: sudo su - postgres

$ psql

postgres=# CREATE DATABASE PostgresDB;

postgres=# CREATE USER PostgresUser WITH PASSWORD 'password';

postgres=# ALTER ROLE PostgressUser SET default_transaction_isolation TO 'read committed'

postgres=# GRANT ALL PRIVILEGES ON DATABASE PostgresDB TO PostgresUser;

Затем я попытался войти в систему несколькими способами:

  • psql -d PostgresDB -U PostgresUser

Возврат: psql: FATAL: Peer authentication failed for user "PostgresUser"

  • psql -d PostgresDB -U PostgresUser -W и ввод пароля
  • psql -d, psql -U PostgresUser -h 127.0.0.1 -d PostgresDB и ввод пароля

Каждый возвращает: psql: FATAL: password authentication failed for user "PostgresUser"

Я сделал все вышеперечисленные попытки войти в систему до и после сброса пароля с помощью: ALTER PostgresUser WITH PASSWORD 'password'

Я проверил файл pg_hba.conf, важные части которого гласят:

# TYPE  DATABASE        USER            ADDRESS                 METHOD

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

postgresql ubuntu-16.04 postgresql-9.5 linux-mint
person TQM    schedule 18.05.2018    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Вы пробовали посмотреть файл журнала?

Чтобы разгадать загадку, попробуйте следующее:

SELECT usename, usesysid FROM pg_user;

Вы заметите, что имя пользователя в нижнем регистре.

Это связано с тем, что PostgreSQL переводит все символы в операторе SQL в нижний регистр (стандарт SQL предписывает, что SQL нечувствителен к регистру).

Однако оболочка чувствительна к регистру, поэтому вы пытаетесь подключиться с именем пользователя, которого не существует.

После этого вы, вероятно, поймете, почему рекомендуется всегда использовать только символы нижнего регистра и цифры в именах объектов базы данных.

Если вы настаиваете на использовании заглавных букв, вам придется заключить имя в двойные кавычки.

person Laurenz Albe    schedule 18.05.2018
comment
Очень полезно знать эту информацию, спасибо! К сожалению, я попытался создать новую базу данных в нижнем регистре и войти в систему, используя все строчные буквы, но, к сожалению, у меня те же проблемы. - person TQM; 19.05.2018
comment
ОК, а что в журнале? Что дает запрос? - person Laurenz Albe; 19.05.2018

arrow_upward
0
arrow_downward

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

Используя инструкции, изложенные в принятом ответе на этот вопрос (Как полностью очистить и переустановить postgresql на ubuntu?), я удалил все, что связано с PostgresSQL на моем компьютере, и переустановил. Мне не удалось войти в систему с: psql -d postgresdb -U postgresdbuser или psql -d postgresdb -U postgresdbuser -W.

Однако мне удалось войти в базу данных с помощью: psql -U postgresdbuser -h 127.0.0.1 -d postgresdb

person TQM    schedule 19.05.2018