Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Сбой проверки подлинности паролей для пользователя
Эта статья поможет решить проблему, которая может возникнуть при подключении к гибкому серверу Базы данных Azure для PostgreSQL.
Симптомы
При попытке подключиться к гибкому серверу Базы данных Azure для PostgreSQL может возникнуть следующее сообщение об ошибке:
psql: ошибка: подключение к серверу в "<server-name.postgres.database.azure.com>" (x.x.x.x.x), сбой порта 5432: не удалось выполнить проверку подлинности паролей для пользователя "<имя> пользователя".
Эта ошибка означает, что пароль, указанный для пользователя <user-name> , является неверным.
После первоначальной ошибки проверки подлинности паролей может появиться другое сообщение об ошибке, указывающее, что клиент пытается повторно подключиться к серверу, на этот раз без шифрования SSL. Эта ошибка возникает из-за конфигурации сервера pg_hba.conf , не разрешающей незашифрованные подключения.
подключение к серверу в "<server-name.postgres.database.azure.com>" (x.x.x.x.x), сбой порта 5432: FATAL: no pg_hba.conf entry for host "y.y.y.y", user "<user-name>", database "postgres", шифрование не
При использовании libpq клиента, поддерживающего протокол SSL, например такие инструменты psql, как , pg_dumpили pgbenchстандартное поведение, чтобы попытаться подключиться один раз с SSL и один раз без него. Причиной этого подхода является то, что сервер может иметь различные pg_hba правила для SSL-подключений и не SSL.
Объединенное сообщение об ошибке, которое вы получаете в этом сценарии, выглядит следующим образом:
psql: ошибка: подключение к серверу на сервере "<server-name.postgres.database.azure.com>" (x.x.x), сбой порта 5432: не удалось выполнить проверку подлинности паролей для подключения пользователя "<имя> пользователя" к серверу в "server-name.postgres.database.azure.com<" (x.x.x.x), порт 5432 завершился ошибкой: НЕ УДАЛОСЬ: НЕ удалось выполнить запись pg_hba.conf для узла ">y.y.y.y". user "user-name<", база данных ">postgres", шифрование не выполняется
Чтобы избежать этой двойной попытки и указать нужный режим SSL, используйте sslmode параметр подключения в конфигурации клиента. Например, если вы используете libpq переменные в оболочке Bash, можно задать режим SSL с помощью следующей команды:
export PGSSLMODE=require
Причина
При подключении к гибкому серверу Базы данных Azure для PostgreSQL возникает ошибка, связанная с проблемами, связанными с проверкой подлинности паролем:
Неверный пароль : сбой проверки подлинности пароля при ошибке пользователя
<user-name>, если пароль для пользователя неверный. Это может произойти из-за неправильного пароля, недавнего изменения пароля, которое не было обновлено в параметрах подключения или других аналогичных проблемах.Пользователь или роль, созданные без пароля другой возможной причиной этой ошибки, создают пользователя или роль в PostgreSQL без указания пароля. Выполнение команд, таких как или
CREATE USER <user-name>без соответствующего оператора пароля, приводит к тому, чтоCREATE ROLE <role-name>пользователь или роль без набора паролей. Попытка подключиться к таким типам пользователей или ролей без настройки пароля приведет к сбою проверки подлинности с ошибкой проверки подлинности паролем.Потенциальное нарушение безопасности, если сбой проверки подлинности непредвиден, особенно если зарегистрированы несколько неудачных попыток, это может указывать на потенциальное нарушение безопасности. Попытки несанкционированного доступа могут активировать такие ошибки.
Разрешение
Если возникла ошибка проверки подлинности паролей для пользователя <user-name>, выполните следующие действия, чтобы устранить проблему.
Попробуйте подключиться к другому инструменту
Если ошибка возникает из приложения, попытайтесь подключиться к базе данных с помощью другого средства, например
psqlpgAdmin, с тем же именем пользователя и паролем. Этот шаг помогает определить, связана ли проблема с клиентом или более широкой проблемой проверки подлинности. Помните о любых соответствующих правилах брандмауэра, которые могут повлиять на подключение. Инструкции по подключению с помощью различных средств см. в колонке "Подключиться" в портал Azure.Изменение пароля
Если после попытки другого средства по-прежнему возникают проблемы с проверкой подлинности паролей, попробуйте изменить пароль для пользователя. Для пользователя администратора можно изменить пароль непосредственно в портал Azure, как описано в этой ссылке. Для других пользователей или администратора в определенных условиях можно изменить пароль из командной строки. Убедитесь, что вы вошли в базу данных в качестве пользователя с
CREATEROLEатрибутом иADMINпараметром для их роли. Команда для изменения пароля:ALTER USER <user-name> PASSWORD '<new-password>';Установка пароля для пользователя или роли, созданной без одного
Если причина ошибки заключается в создании пользователя или роли без пароля, войдите в экземпляр PostgreSQL и задайте пароль для роли. Для ролей, созданных без привилегий
LOGIN, обязательно предоставьте этому привилегию вместе с настройкой пароля:ALTER ROLE <role-name> LOGIN; ALTER ROLE <role-name> PASSWORD '<new-password>';Если вы подозреваете потенциальное нарушение безопасности
Если вы подозреваете, что потенциальное нарушение безопасности вызывает несанкционированный доступ к гибкому серверу Базы данных Azure для PostgreSQL, выполните следующие действия, чтобы устранить эту проблему:
Включите запись журнала, если запись журнала еще не включена, получите ее сейчас. Запись журнала для отслеживания ключа для отслеживания действий базы данных и перехвата любых нечетных шаблонов доступа. Это можно сделать несколькими способами, включая журналы Log Analytics и сервера Azure Monitor, которые помогают хранить и анализировать журналы событий базы данных.
- Log Analytics, см. инструкции по настройке Azure Monitor Log Analytics здесь: Настройка и доступ к журналам в гибком сервере базы данных Azure для PostgreSQL.
- Журналы сервера для управления журналами практических действий см. в разделе "Настройка записи журналов сервера PostgreSQL" и журналов обновления основных версий.
Определение IP-адреса злоумышленника
Просмотрите журналы, чтобы найти IP-адрес, из которого выполняются попытки несанкционированного доступа. Если злоумышленник использует
libpqсредство на основе, вы увидите IP-адрес в записи журнала, связанной с неудачной попыткой подключения:подключение к серверу в "<server-name.postgres.database.azure.com>" (x.x.x.x.x), сбой порта 5432: FATAL: no pg_hba.conf entry for host "y.y.y.y", user "<user-name>", database "postgres", шифрование не
В этом примере
y.y.y.yиспользуется IP-адрес, с которого злоумышленник пытается подключиться.Измените параметр,
log_line_prefixчтобы улучшить ведение журнала и упростить устранение неполадок, необходимо изменитьlog_line_prefixпараметр в конфигурации PostgreSQL, чтобы включить IP-адрес удаленного узла. Чтобы записать имя удаленного узла или IP-адрес, добавьте в нее%hlog_line_prefixescape-код.Например, можно изменить
log_line_prefixследующий формат для комплексного ведения журнала:log_line_prefix = '%t [%p]: [%l-1] db=%d,user=%u,app=%a,client=%h 'Этот формат включает:
-
%tметка времени события -
%pидентификатор процесса -
[%l-1]для номера строки сеанса -
%dимя базы данных -
%uимя пользователя -
%aимя приложения -
%hдля IP-адреса клиента
Используя этот префикс строки журнала, вы можете отслеживать время, идентификатор процесса, пользователя, приложение и IP-адрес клиента, связанный с каждой записью журнала, предоставляя ценный контекст для каждого события в журнале сервера.
-
Заблокируйте IP-адрес злоумышленника в журналы, чтобы обнаружить все подозрительные IP-адреса, которые продолжают отображаться в попытках несанкционированного доступа. После того как вы найдете эти IP-адреса, немедленно заблокируйте их в параметрах брандмауэра. Это отключает доступ и предотвращает более несанкционированные попытки. Кроме того, ознакомьтесь с правилами брандмауэра, чтобы убедиться, что они не слишком удостоверяются. Слишком широкие правила могут предоставлять базу данных потенциальным атакам. Ограничить доступ только к известным и необходимым диапазонам IP-адресов.
Выполнив следующие действия, вы сможете устранить проблемы с проверкой подлинности и успешно подключиться к гибкому серверу Базы данных Azure для PostgreSQL. Если вы по-прежнему сталкиваетесь с проблемами после указания, пожалуйста, не стесняйтесь подать запрос в службу поддержки.