ユーザー <user-name> のパスワード認証に失敗しました

この記事は、Azure Database for PostgreSQL - フレキシブル サーバーに接続する際に発生する可能性のある問題を解決するのに役立ちます。

現象

Azure Database for PostgreSQL - フレキシブル サーバーに接続しようとしたときに、次のエラー メッセージが表示される場合があります。

psql: error: connection to server at "<サーバー名>.postgres.database.azure.com" (x.x.x.x), port 5432 failed: FATAL: password authentication failed for user "<ユーザー名>"

このエラーは、ユーザー <user-name> に指定されたパスワードが正しくないことを示します。

最初のパスワード認証エラーの後に、クライアントが、今度は SSL 暗号化を使用せずに、サーバーに接続しようとしていることを示すエラー メッセージが表示される場合があります。 このエラーは、サーバーの pg_hba.conf 構成で、暗号化されていない接続が許可されていないために発生します。

connection to server at "<サーバー名>.postgres.database.azure.com" (x.x.x.x), port 5432 failed: FATAL: no pg_hba.conf entry for host "y.y.y.y", user "<ユーザー名>", database "postgres", no encryption

SSL をサポートする libpq クライアント (psql、pg_dump、pgbench などのツール) を使用する場合、SSL を使用して 1 回、SSL を使用しないで 1 回、接続を試みるのは標準的な動作です。 このアプローチが採用されるのは、サーバーで SSL 接続と非 SSL 接続に対して異なる pg_hba 規則を設定できるためです。 このシナリオで受け取るエラー メッセージの組み合わせは、次のようになります。

psql: error: connection to server at "<サーバー名>.postgres.database.azure.com" (x.x.x.x), port 5432 failed: FATAL: password authentication failed for user "<ユーザー名>" connection to server at "<サーバー名>.postgres.database.azure.com" (x.x.x.x), port 5432 failed: FATAL: no pg_hba.conf entry for host "y.y.y.y", user "<ユーザー名>", database "postgres", no encryption

この 2 段階試行を回避し、目的の SSL モードを指定するには、クライアント構成で sslmode 接続オプションを使用します。 たとえば、bash シェルで libpq 変数を使用している場合、次のコマンドを使用して SSL モードを設定できます。

export PGSSLMODE=require

原因

Azure Database for PostgreSQL - フレキシブル サーバーに接続するときに発生するエラーは、主に、パスワード認証に関する問題に起因します。

• パスワードが正しくない "ユーザー <user-name> のパスワード認証に失敗しました" エラーは、ユーザーのパスワードが正しくない場合に発生します。 これは、パスワードの入力ミス、接続設定で更新されていない最近のパスワード変更、またはその他の同様の問題に起因して発生します。

• ユーザーまたはロールがパスワードなしで作成されている このエラーのもう 1 つの原因として考えられるのは、パスワードを指定しないで、PostgreSQL でユーザーまたはロールが作成されていることです。 CREATE USER <user-name>や CREATE ROLE <role-name> などのコマンドを、付随するパスワード ステートメントを指定しないで実行すると、ユーザーまたはロールにパスワードが設定されません。 パスワードを設定されていないこれらの種類のユーザーまたはロールに接続しようとすると、認証は、パスワード認証の失敗エラーで失敗します。

• 潜在的なセキュリティ侵害 予期しない認証エラーが発生した場合 (特に失敗した試行が複数記録されている場合)、潜在的なセキュリティ侵害を示している可能性があります。 不正アクセス試行によって、このようなエラーが発生する可能性があります。

解決方法

"ユーザー <user-name> のパスワード認証に失敗しました" エラーが発生した場合、以下の手順に従って問題を解決します。

• 別のツールを使用して接続を試みる

  エラーがアプリケーションから発生した場合、同じユーザー名とパスワードを使用し、psql や pgAdmin などの別のツールを使用してデータベースへの接続を試みます。 この手順は、問題がクライアントに固有であるか、より広範な認証問題であるかを判断するのに役立ちます。 接続に影響している可能性がある関連するファイアウォール規則がないかどうかに注意してください。 さまざまなツールを使用して接続する手順については、Azure portal の [接続] ブレードを参照してください。

• パスワードを変更する

  別のツールを試した後もパスワード認証問題が発生する場合は、ユーザーのパスワードの変更を検討します。 管理者ユーザーの場合、このリンクで説明されているように、Azure portal で直接パスワードを変更できます。 管理者以外のユーザー、または特定の条件下の管理者ユーザーの場合、コマンド ラインからパスワードを変更できます。 CREATEROLE 属性と、ロールの ADMIN オプションを持つユーザーとしてデータベースにログインしていることを確認してください。 パスワードを変更するコマンドは、次のとおりです。

  ALTER USER <user-name> PASSWORD '<new-password>';
  

• パスワードなしで作成されたユーザーまたはロールのパスワードを設定する

  エラーの原因が、パスワードなしでユーザーまたはロールが作成されたことにある場合、PostgreSQL インスタンスにログインし、ロールのパスワードを設定します。 LOGIN 特権なしで作成されたロールの場合、パスワードを設定すると共に、この特権を必ず付与してください。

  ALTER ROLE <role-name> LOGIN;
  ALTER ROLE <role-name> PASSWORD '<new-password>';
  

• 潜在的なセキュリティ侵害の疑いがある場合

  潜在的なセキュリティ侵害が原因で、Azure Database for PostgreSQL - フレキシブル サーバーへの不正アクセスが発生している疑いがある場合は、以下の手順に従って問題に対処します。

  1. ログ キャプチャを有効にする ログ キャプチャがまだオンになっていない場合は、今すぐ設定します。 ログ キャプチャは、データベース アクティビティを監視し、異常なアクセス パターンを検出するための鍵となります。 これを行うには、Azure Monitor Log Analytics やサーバー ログなど、データベース イベント ログの格納と分析に役立ついくつかの方法があります。

     • Log Analytics。Azure Monitor Log Analytics のセットアップ手順については、「Azure Database for PostgreSQL - フレキシブル サーバーでのログの構成とアクセス」を参照してください。
     • サーバー ログ。実践的なログ管理については、「PostgreSQL サーバー ログとメジャー バージョンのアップグレード ログのキャプチャを構成する」を参照してください。

  2. 攻撃者の IP アドレスを特定する

     • ログを確認して、不正アクセスを試行している IP アドレスを見つけます。 攻撃者が libpq ベースのツールを使用している場合、失敗した接続の試行に関連付けられたログ エントリに IP アドレスが表示されます。

       connection to server at "<サーバー名>.postgres.database.azure.com" (x.x.x.x), port 5432 failed: FATAL: no pg_hba.conf entry for host "y.y.y.y", user "<ユーザー名>", database "postgres", no encryption

       この例では、y.y.y.y が、攻撃者が接続しようとしている IP アドレスです。

     • log_line_prefix を変更する ログを改善し、トラブルシューティングを容易にするには、リモート ホストの IP アドレスを含むように PostgreSQL 構成の log_line_prefix パラメーターを変更する必要があります。 リモート ホスト名または IP アドレスをログするには、%h エスケープ コードを log_line_prefix に追加します。

       たとえば、log_line_prefix を次の形式に変更して、包括的にログすることができます。

       log_line_prefix = '%t [%p]: [%l-1] db=%d,user=%u,app=%a,client=%h '
       

       この形式には、次のものが含まれます。

       • %t (イベントのタイムスタンプ)
       • %p (プロセス ID)
       • [%l-1] (セッション行番号)
       • %d (データベース名)
       • %u (ユーザー名)
       • %a (アプリケーション名)
       • %h (クライアント IP アドレス)

       このログ行プレフィックスを使用すると、各ログ エントリに関連付けられた時刻、プロセス ID、ユーザー、アプリケーション、クライアント IP アドレスを追跡できため、サーバー ログ内の各イベントに関する貴重なコンテキストを提供できます。

  3. 攻撃者の IP アドレスをブロックする ログを詳しく調べて、不正アクセス試行で継続的に出現する疑わしい IP アドレスを特定します。 これらの IP が見つかったらすぐに、ファイアウォール設定でそれらをブロックします。 これにより、アクセスが遮断され、それ以降の不正な試行が防止されます。 さらに、ファイアウォール規則を確認して、規則が過度に寛容にならないようにします。 規則が大まかすぎると、データベースが潜在的な攻撃にさらされる可能性があります。 アクセスを既知の必要な IP 範囲のみに制限します。

これらの手順に従うと、認証の問題を解決し、Azure Database for PostgreSQL - フレキシブル サーバーに正常に接続できます。 提供されているガイダンスに従った後も問題が発生する場合は、ご遠慮なく サポート チケットを提出してください。