Postgres 認証失敗エラー「password authentication failed」とは？原因と直し方

By /

PostgreSQL 認証失敗エラー「password authentication failed」とは？原因と直し方の徹底解説

はじめに

PostgreSQLは、その堅牢性、高機能性、そしてオープンソースであることから、世界中で広く利用されているリレーショナルデータベースシステムです。小規模なプロジェクトから大規模なエンタープライズシステムまで、多岐にわたる用途で活躍しています。

しかし、データベースを運用する上で、接続に関する問題は避けて通れません。その中でも特に頻繁に遭遇するエラーの一つが、「password authentication failed」です。このエラーメッセージは、文字通り「パスワード認証に失敗しました」という意味であり、データベースに接続しようとした際に、提供されたパスワードが正しくないために発生します。

このエラーは一見単純なパスワード間違いに思えますが、実際にはさまざまな原因が考えられます。単純な入力ミスから、複雑なサーバー設定、クライアント設定、さらにはネットワークの問題まで、多岐にわたる要因が認証失敗を引き起こす可能性があります。

この記事では、PostgreSQLの「password authentication failed」エラーについて、その基本的な意味から、考えられるあらゆる原因、そしてそれぞれの原因に対する具体的な直し方、さらに将来的なエラーを防ぐための予防策まで、詳細かつ網羅的に解説します。この記事を読むことで、この厄介なエラーに直面した際に、冷静かつ体系的に原因を特定し、問題を解決できるようになることを目指します。

データベースのトラブルシューティングは、時に時間と労力を要しますが、一つずつ可能性を潰していくことで必ず解決の糸口が見つかります。さあ、「password authentication failed」エラーの謎を解き明かし、スムーズなデータベース運用を取り戻しましょう。

「password authentication failed」エラーとは？

「password authentication failed」というエラーメッセージは、PostgreSQLサーバーが、クライアントからの接続要求に対して、提供されたパスワードが正しいことを確認できなかった場合に返されるものです。

このエラーは、クライアント（アプリケーション、コマンドラインツール、管理ツールなど）がPostgreSQLサーバーへの接続を試みる際に発生します。具体的には、クライアントがサーバーに対して、接続したいデータベース、使用するユーザー名、そしてパスワードを送信し、サーバーがその情報を受け取って認証プロセスを実行する段階で、パスワードが検証に失敗した場合にこのエラーが通知されます。

エラーメッセージの典型的な形式:

エラーメッセージは、使用しているクライアントツールやPostgreSQLのバージョン、設定によって多少異なる場合がありますが、中心的な部分は共通しています。

psql: error: connection to server at "localhost" (::1), port 5432 failed: password authentication failed for user "myuser"

あるいは、よりシンプルにパスワード認証失敗のみを示す場合もあります。

password authentication failed

上記の例では、「connection to server at "localhost" (::1), port 5432 failed」という接続情報に続いて、「password authentication failed for user "myuser"」と、認証に失敗したユーザー名が表示されています。この情報は、トラブルシューティングを行う上で非常に重要な手がかりとなります。

他の認証エラーとの違い:

PostgreSQLでは、認証プロセス中に発生する可能性のあるエラーは「password authentication failed」だけではありません。例えば、以下のようなエラーも存在します。

  • FATAL: role "<ユーザー名>" does not exist: 指定されたユーザー名（ロール）がPostgreSQLサーバー上に存在しない場合に発生します。
  • FATAL: database "<データベース名>" does not exist: 指定されたデータベース名がPostgreSQLサーバー上に存在しない場合に発生します。
  • FATAL: no pg_hba.conf entry for host "<クライアントIP>", user "<ユーザー名>", database "<データベース名>", SSL off/on: クライアントのIPアドレス、ユーザー、データベース、SSL設定の組み合わせに対応するエントリが pg_hba.conf ファイルに見つからなかった場合に発生します。これは認証方式の設定ミスに起因するエラーですが、「password authentication failed」とは異なります。パスワード認証が始まる前に、そもそも接続が許可されていない段階で発生します。

「password authentication failed」は、ユーザー名とデータベース名は存在し、かつ pg_hba.conf の設定によってその接続が許可されているが、提供されたパスワードがサーバーに登録されているパスワードと一致しない場合に発生するエラーです。

つまり、このエラーが発生した場合、問題は主に以下のいずれかにあると推測できます。

  1. クライアントがサーバーに送信したパスワードが間違っている。
  2. サーバーに登録されているユーザーのパスワードが、クライアントが期待しているものと異なる。
  3. 認証方式の設定が原因で、パスワードの検証が正しく行われていない（例えば、クライアントが期待する方式とサーバーの設定が異なる場合）。

これらの可能性を踏まえて、次に具体的な原因を掘り下げていきましょう。

エラーの主な発生原因

「password authentication failed」エラーは、さまざまな要因によって引き起こされます。ここでは、考えられる主な原因を一つずつ詳しく見ていきます。

1. 最も一般的な原因：パスワードの誤入力

最も頻繁に遭遇する原因は、単純なパスワードの入力ミスです。これは人間が手入力する場合だけでなく、コピー＆ペーストや設定ファイルからの読み込みでも発生する可能性があります。

  • 単純な打ち間違い: キーボードでの入力時に発生する最も基本的なミスです。
  • CapsLock/NumLockの状態: CapsLockがオンになっている、またはNumLockがオフになっていることに気づかずに入力した場合、意図しないパスワードになります。
  • コピー＆ペースト時の問題:
    • パスワードの前後に不要な空白文字が含まれてしまう。
    • 改行コードが含まれてしまう。
    • 見た目は同じでも異なる文字コードでペーストされる。
    • コピー元とペースト先の環境で文字セットやエンコーディングが異なる。
  • キーボードレイアウトの違い: OSやアプリケーションで設定されているキーボードレイアウトが、パスワードを作成したときの環境と異なる場合、入力される文字が変わってしまうことがあります（例: 日本語キーボードとUSキーボードでの記号の位置の違い）。
  • パスワードマネージャーの問題: パスワードマネージャーからコピー＆ペーストした場合でも、予期せぬ問題が発生することがあります。また、オートフィル機能が正しく機能しない場合もあります。

2. ユーザー名の誤り

ユーザー名が間違っている場合も、直接的な「password authentication failed」エラーにつながることがあります。正確には、「role does not exist」エラーになることが多いですが、文脈によってはパスワード認証の段階で失敗とみなされることもあります。また、ユーザー名は正しいが、そのユーザーに設定されたパスワードが想定と異なる、というケースもこの範疇に含まれます。

  • 存在するユーザー名と異なる: 指定したユーザー名がPostgreSQLに登録されていない。
  • 大文字・小文字の違い: PostgreSQLのユーザー名（ロール名）は、デフォルトでは大文字小文字を区別します。例えば、「myuser」と「MyUser」は異なるユーザーとして扱われます。意図したユーザー名と大文字小文字の区別が異なっている可能性があります。
  • デフォルトユーザー名の誤解: OSのユーザー名や、他のデータベースシステムのデフォルトユーザー名と混同している可能性があります。PostgreSQLのデフォルトスーパーユーザー名は通常 postgres ですが、インストール方法やOSによっては異なる場合があります。

3. 接続先データベース名の誤り

接続しようとしているデータベース名が間違っている場合も、エラーの原因となります。これも通常は「database does not exist」エラーになりますが、特定の認証設定（例: ユーザー名と同名のデータベースにのみ接続許可）によっては、データベース名の間違いが間接的に認証失敗につながることもあります。

  • 存在するデータベース名と異なる: 指定したデータベース名がPostgreSQLサーバー上に存在しない。
  • デフォルトデータベース名の誤解: PostgreSQLでは、デフォルトで接続ユーザー名と同じ名前のデータベースへの接続が試みられることがあります。または、デフォルトの postgres データベースへの接続を意図していたが、別のデータベース名を指定してしまったなどが考えられます。

4. 接続ホスト/IPアドレスの誤り

接続しようとしているPostgreSQLサーバーのホスト名またはIPアドレスが間違っている場合、そもそもサーバーに接続できません。これは通常「connection refused」などのネットワークレベルのエラーになります。しかし、pg_hba.conf の設定が接続元ホスト/IPアドレスによって異なる認証方式を要求している場合、アドレスの誤りが認証方式の不一致を引き起こし、結果として「password authentication failed」になる可能性があります。

  • サーバーのアドレスが間違っている: 存在しないアドレスを指定している、または異なるサーバーのアドレスを指定している。
  • ローカルホストとリモート接続の違い: ローカルからの接続 (localhost, 127.0.0.1, ::1) と、ネットワーク経由でのリモート接続では、pg_hba.conf で適用されるルールが異なることが一般的です。ローカル接続の設定は正しいが、リモート接続の設定が間違っている、またはその逆の可能性があります。

5. 認証方式の設定ミス (pg_hba.conf)

これは「password authentication failed」エラーの原因として、パスワードの誤入力に次いで多い、あるいはより根本的な問題となるケースです。pg_hba.conf (Host-Based Authentication) ファイルは、PostgreSQLサーバーへの接続を、接続元ホスト、データベース、ユーザーごとにどのように許可するか（または拒否するか）、そしてどのような認証方式を使用するかを定義する非常に重要な設定ファイルです。

  • pg_hba.conf ファイルの役割: クライアントが接続要求を送ると、PostgreSQLサーバーはこのファイルを上から順に読み込み、接続要求に合致する最初のエントリを見つけます。そのエントリに定義された認証方式（例: md5, scram-sha-256, trust, reject, ident, peerなど）に従って認証処理を行います。
  • 認証方式の誤設定:
    • クライアントがパスワード認証を試みているのに、サーバー側の設定が trust (パスワード不要) や reject (拒否) になっている場合、認証は成功しません。
    • クライアントとサーバーで使用されるパスワードハッシュ方式が一致しない場合（例: サーバーは scram-sha-256 を要求しているが、クライアントは古い md5 形式のパスワードを送信している）。PostgreSQL 10以降では scram-sha-256 が推奨され、バージョンによってはデフォルトになっています。古いクライアントライブラリやツールが新しいハッシュ方式に対応していない場合があります。
    • ident や peer といったパスワードを使用しない認証方式が誤って設定されている場合。これらの方式はOSレベルのユーザー情報を利用するため、パスワード認証は行われません。
  • 接続元, ユーザー, データベース, アドレスの組み合わせが正しくない: pg_hba.conf のエントリは、接続タイプ (local or host), データベース, ユーザー, 接続元アドレス, 認証方式という形式で記述されます。これらの組み合わせが、クライアントからの接続要求と正確に一致しないと、意図した認証方式が適用されないか、あるいは別のエントリが適用されてしまう可能性があります。
  • エントリの順序: pg_hba.conf は上から順に評価されます。より具体的なルール（特定のIPアドレス範囲など）は、より一般的なルール（0.0.0.0/0 など）よりも前に記述する必要があります。順序が誤っているために、意図しないエントリ（例えば reject や trust）が先にマッチしてしまい、パスワード認証に進めないことがあります。
  • 設定変更後の反映: pg_hba.conf ファイルを変更しただけでは設定は反映されません。PostgreSQLサーバーに設定を再読み込みさせるか、サーバーを再起動する必要があります (pg_ctl reload や systemctl reload postgresql など)。これを忘れていると、変更したはずの設定が有効になっていないために認証失敗が継続します。

6. PostgreSQLサーバーのユーザー設定ミス

認証に使おうとしているPostgreSQLユーザー（ロール）自体に問題がある場合です。

  • ユーザーが存在しない、または削除されている: role "<ユーザー名>" does not exist エラーになることが多いですが、設定によっては認証失敗となることもあります。
  • ユーザーにパスワードが設定されていない、または意図しないパスワードが設定されている: ユーザーを作成した際にパスワードを設定し忘れた、あるいは後からパスワードを変更したが、クライアント側が古いパスワードのままになっている。
  • ユーザーにLOGIN権限がない: PostgreSQLのロールには LOGIN 属性が必要です。この属性がないロールは、データベースへの接続に使用できません。通常、CREATE USER コマンドは自動的に LOGIN 属性を付与しますが、CREATE ROLE で作成したロールには別途 LOGIN 属性を付与する必要があります。
  • パスワードハッシュ方式の問題: ユーザーのパスワードが、サーバーが要求する認証方式（md5 vs scram-sha-256）に対応する形式でハッシュ化されていない可能性があります。特に古いサーバーから新しいサーバーにデータ（含むパスワードハッシュ）を移行した場合や、認証方式の設定を変更した場合に発生しうる問題です。

7. クライアント側の問題

接続を試みているクライアントアプリケーションやツール自体の設定ミスや問題も原因となります。

  • 接続文字列/URLの記述ミス: 環境変数、設定ファイル、コードなどで接続情報（ホスト、ポート、データベース、ユーザー、パスワード）を指定する際の記述ミス。特に、接続文字列の形式がライブラリやツールによって異なるため注意が必要です。
  • 環境変数の設定ミス: PGPASSWORD, PGUSER, PGHOST, PGPORT, PGDATABASE などの環境変数を使用している場合、これらの値が誤っている可能性があります。また、意図しない環境変数が設定されている場合もあります。
  • 使用しているクライアントツールの設定ミス: pgAdmin, DBeaverなどのGUIツールや、特定のアプリケーションの設定画面で、接続情報が正しく入力されていない。
  • クライアントライブラリ/ドライバの問題: 使用しているデータベースドライバ（JDBC, Npgsql, psycopg2など）が古い、またはPostgreSQLサーバーのバージョンや認証方式に対応していない可能性があります。

8. PostgreSQLサーバーのバージョン間の違い

PostgreSQLのバージョンアップにより、デフォルトの認証方式や設定ファイル（postgresql.conf）の推奨設定が変更されることがあります。

  • デフォルト認証方式の変更: PostgreSQL 10以降では、パスワード認証のデフォルトが md5 から scram-sha-256 に変更されました。サーバー側が scram-sha-256 を要求しているのに、クライアント側のライブラリやツールがこれに対応しておらず、md5 で認証を試みて失敗する、というケースがよくあります。
  • 設定パラメータの変更: postgresql.conf の関連パラメータ（password_encryption, listen_addressesなど）のデフォルト値や意味合いが変更されている可能性があります。

9. ネットワーク設定、ファイアウォール

厳密には「password authentication failed」エラーそのものではなく、その前段階で発生する問題ですが、認証プロセスに到達できない原因として関連するため触れておきます。クライアントからサーバーへのTCP/IP接続自体が、ファイアウォールやネットワークルーティングの問題でブロックされている場合、そもそも認証フェーズに進めません。

  • サーバー側のファイアウォール: PostgreSQLが使用するポート（デフォルト 5432）がサーバー側のファイアウォール（iptables, firewalld, Windows Firewallなど）でブロックされている。
  • クライアント側のファイアウォール: クライアント側のファイアウォールが、特定のポートへのアウトバウンド接続を制限している。
  • ネットワーク経路の問題: VPN、プロキシ、ルーターなどのネットワーク機器が接続を妨げている。

これらの場合、エラーメッセージは通常「connection refused」やタイムアウトになりますが、場合によっては認証失敗と誤解することもあるかもしれません。ただし、「password authentication failed」というメッセージが明確に出ている場合は、少なくともTCP/IP接続は成功し、認証フェーズには到達していると考えられます。

10. その他の可能性

  • 複数のPostgreSQLインスタンス: 同じサーバー上で複数のPostgreSQLインスタンスが異なるポートで稼働しており、意図しないインスタンスに接続しようとしている。
  • OSユーザーとPostgreSQLユーザー（Peer認証など）: Peer認証やIdent認証を使用している場合、OSユーザー名とPostgreSQLユーザー名の一致が必要となります。これが一致しない場合、認証は失敗します。
  • サーバー側のリソース問題: ディスク容量不足、メモリ不足などが深刻な場合、PostgreSQLサーバーが正常に動作せず、認証処理が完了できない可能性もゼロではありません（非常に稀なケースですが）。

これらの原因を頭に入れつつ、次に具体的な直し方、すなわち体系的なトラブルシューティングの手順を見ていきましょう。

エラーの直し方・具体的なトラブルシューティング手順

「password authentication failed」エラーに遭遇したら、落ち着いて、以下のステップを順に追って原因を特定し、解決策を実行してください。

ステップ1：基本的な接続情報の再確認

最も基本的なことから始めましょう。エラーメッセージに示されている情報（ユーザー名、ホスト名、ポート）と、あなたが接続しようとしている情報が一致しているかを確認します。

  • ユーザー名: 接続に使用しているPostgreSQLユーザー名は本当に正しいですか？大文字/小文字の区別は正確ですか？
  • パスワード: 入力したパスワードは、そのユーザーに設定されているパスワードと正確に一致しますか？Caps LockやNum Lockの状態を確認してください。手入力の場合は、落ち着いてゆっくりと再入力してみてください。パスワードマネージャーやコピー＆ペーストを使用している場合は、前後に不要な文字が入っていないか注意深く確認してください。
  • ホスト名/IPアドレス: 接続しようとしているPostgreSQLサーバーのアドレスは正しいですか？localhost (または 127.0.0.1, ::1) への接続なのか、リモートサーバーへの接続なのか、意図と一致していますか？
  • ポート番号: PostgreSQLサーバーがListenしているポート番号は正しいですか？デフォルトは 5432 ですが、変更されている可能性もあります。接続情報で明示的にポートを指定しているか確認してください。

アクション: これらの基本的な情報をもう一度確認し、必要であれば再入力して接続を試みます。特に手入力でのパスワード間違いは非常に多いため、まずここから疑うのが定石です。

ステップ2：psqlコマンドでの接続テスト

GUIツールやアプリケーションからの接続でエラーが出ている場合、PostgreSQLの公式コマンドラインツールである psql を使用して接続テストを行うのが、原因を切り分ける上で非常に有効です。psql はPostgreSQLクライアントの基本であり、その挙動は信頼性が高いため、psql で接続できるかどうかで、問題がサーバー側にあるのか、それとも使用している別のクライアントツール/アプリケーション側にあるのかを判断できます。

psqlでの接続テスト方法:

ターミナルまたはコマンドプロンプトを開き、以下の形式でコマンドを実行します。

bash
psql -h <ホスト名またはIPアドレス> -p <ポート番号> -U <ユーザー名> -d <データベース名>

例:

bash
psql -h localhost -p 5432 -U myuser -d mydatabase

  • <ホスト名またはIPアドレス>: 接続先のサーバーアドレスを指定します。ローカルホストなら localhost または 127.0.0.1 です。
  • <ポート番号>: PostgreSQLがListenしているポート番号を指定します。デフォルトは 5432 です。
  • <ユーザー名>: 接続に使用するPostgreSQLユーザー名を指定します。
  • <データベース名>: 接続先のデータベース名を指定します。デフォルトデータベース（ユーザー名と同名、または postgres）に接続する場合は省略できることもありますが、明示的に指定するのが確実です。

パスワードはコマンドラインのオプション (-W) で指定することもできますが、セキュリティ上、コマンド実行後にプロンプトが表示されてから入力する方が安全です。上記のコマンドを実行すると、以下のようにパスワード入力を求められます。

Password for user myuser:

ここでパスワードを正確に入力します。

結果の判断:

  • 接続成功: psql プロンプト (mydatabase=>) が表示されれば、psql を使った接続は成功です。この場合、PostgreSQLサーバー側の設定（pg_hba.conf やユーザー設定）や基本的な認証方式には問題ない可能性が高いです。問題は、あなたが元々使っていたクライアントツールやアプリケーションの設定（接続文字列、ライブラリ、ツールのバグなど）にあると考えられます。そのクライアント側の設定を詳しく確認してください。
  • 「password authentication failed」エラー: psql でも同じエラーが発生した場合、問題はPostgreSQLサーバー側、あるいはサーバーとクライアント共通の認証方式設定にある可能性が高いです。次のステップに進んで、サーバー側の設定を確認する必要があります。
  • 他のエラー: 「connection refused」、「role does not exist」、「database does not exist」、「no pg_hba.conf entry …」などのエラーが表示された場合は、「password authentication failed」以外の問題です。それぞれのエラーメッセージに基づいて原因を特定し、対処してください。

ステップ3：PostgreSQLサーバー側の設定確認 (pg_hba.conf)

psql でも認証失敗エラーが発生した場合、サーバー側の設定、特に pg_hba.conf ファイルに問題がある可能性が非常に高いです。

1. pg_hba.conf ファイルの場所特定:

pg_hba.conf ファイルは、PostgreSQLのデータディレクトリ内にあります。データディレクトリの場所は、PostgreSQLのインストール方法やOSによって異なります。一般的な場所は以下の通りです。

  • Linux (Debian/Ubuntu): /etc/postgresql/<バージョン>/main/pg_hba.conf
  • Linux (RHEL/CentOS): /var/lib/pgsql/data/pg_hba.conf (または /var/lib/pgsql/<バージョン>/data/pg_hba.conf)
  • Windows: PostgreSQLインストールディレクトリ内の data サブディレクトリ (例: C:\Program Files\PostgreSQL\<バージョン>\data\pg_hba.conf)

正確な場所が分からない場合は、psql にスーパーユーザー（通常は postgres）で接続できれば、SHOW data_directory; コマンドでデータディレクトリの場所を確認できます。または、SHOW config_file; コマンドで postgresql.conf の場所を確認し、そのディレクトリにあることが多いです。

2. pg_hba.conf ファイルの内容確認:

テキストエディタで pg_hba.conf ファイルを開き、内容を確認します。コメント行 (# で始まる行) を除外し、クライアントからの接続要求に合致するエントリを探します。

エントリの一般的な形式は以下の通りです。

TYPE DATABASE USER ADDRESS METHOD [OPTIONS]

  • TYPE: local (Unixドメインソケット), host (TCP/IPv4), hostssl (SSL経由のTCP/IPv4), hostnossl (SSLなしのTCP/IPv4), hostgssenc (GSSAPI暗号化), hostnogssenc (GSSAPI暗号化なし), hostsnie (SNI SSL経由)
  • DATABASE: 接続先のデータベース名。all は全てのデータベース、特定のデータベース名、カンマ区切りのリスト、sameuser (接続ユーザーと同名のデータベース), samerole (接続ユーザーがメンバーであるロールと同名のデータベース), replication (レプリケーション接続) が指定可能。
  • USER: 接続に使用するPostgreSQLユーザー名。all は全てのユーザー、特定のユーザー名、カンマ区切りのリスト、@グループ名 が指定可能。
  • ADDRESS: 接続元のクライアントアドレス。all は全てのアドレス、特定のIPアドレス、CIDR形式のIPアドレス範囲 (例: 192.168.1.0/24), ホスト名 (名前解決が必要), samehost (サーバー自身), samenet (サーバーと同じサブネット) が指定可能。local タイプの場合はこのフィールドは不要です。
  • METHOD: 認証方式。trust, reject, md5, scram-sha-256, password, gssapi, ssi, krb5, ident, peer, ldap, radius, cert, pam などがあります。「password authentication failed」は、通常 md5, scram-sha-256, password などのパスワード認証方式を選択している場合に発生します。
  • [OPTIONS]: 認証方式に関するオプション。include_realm=0|1, map=マップ名, auth_茴script=/path/to/script など。

確認ポイント:

  • 該当エントリの存在: クライアントの接続要求（接続タイプ、データベース、ユーザー、接続元アドレス）に合致するエントリが存在しますか？
  • 認証方式 (METHOD): 該当するエントリの認証方式が md5 または scram-sha-256 (あるいは単に password) になっていますか？もし trust や reject になっている場合、パスワード認証はスキップされるか拒否されます。もし ident や peer になっている場合、OSレベルの認証が行われます。
  • アドレス (ADDRESS): クライアントの接続元IPアドレスまたはホスト名が、そのエントリの ADDRESS 範囲に含まれていますか？例えば、リモートから接続しているのに ADDRESS が 127.0.0.1/32 や ::1/128 のローカルアドレスしか許可していない場合、リモート接続には別のエントリが必要です。
  • ユーザー (USER) とデータベース (DATABASE): 接続に使用しているユーザー名とデータベース名が、エントリの USER と DATABASE フィールドに合致していますか？
  • エントリの順序: クライアントの接続要求に合致するエントリが複数ある場合、pg_hba.conf のより上の行にあるエントリが優先されます。意図しないエントリ（例: 範囲が広い reject エントリなど）が先にマッチしていないか確認してください。

よくある設定ミス例:

  • リモートからの接続を許可したいのに、pg_hba.conf に host タイプのエントリがない、または ADDRESS がローカルアドレスのみに限定されている。
  • 認証方式が md5 や scram-sha-256 になっているが、クライアント側が想定しているパスワードハッシュ方式と異なる。
  • ユーザー名やデータベース名が正確に記述されていない (all を使うか、具体的な名前を記述する)。
  • 広範なアドレス範囲 (0.0.0.0/0 や ::/0) に対して trust 認証を設定してしまっている（これはセキュリティリスクが高い）。

アクション: pg_hba.conf の内容を確認し、必要であれば修正します。例えば、特定のIPアドレスからのリモート接続を md5 認証で許可したい場合は、以下の様な行を追加または修正します（既存の行をコピーして修正するのが安全です）。

“`

TYPE DATABASE USER ADDRESS METHOD

host all myuser 192.168.1.100/32 md5
“`

all の代わりに特定のデータベース名やユーザー名を指定することもできます。より広範なネットワークからのアクセスを許可する場合は、192.168.1.0/24 のようにCIDRブロックを指定します。ただし、0.0.0.0/0 や ::/0 を安易に使用すると、インターネット上のどこからでも接続試行が可能になるため、非常に危険です。必要な範囲に限定して設定してください。

3. 設定変更の反映:

pg_hba.conf ファイルを編集・保存したら、PostgreSQLサーバーに設定を再読み込みさせる必要があります。サーバーを完全に再起動する必要はありません（再起動は実行中のセッションを切断するため影響が大きい）。

  • pg_ctl コマンドを使用する場合:
    bash
    pg_ctl reload -D <データディレクトリのパス>
    または、サーバーのPIDを指定して
    bash
    pg_ctl reload -D $(pg_ctl status -D <データディレクトリのパス> | grep PID | awk '{print $4}')
  • systemd を使用している場合 (Linux):
    bash
    sudo systemctl reload postgresql
    (サービス名は postgresql の他に、postgresql-<バージョン>, postgresql-server などOSによって異なる場合があります)
  • Windowsサービスを使用している場合: サービス管理ツールからPostgreSQLサービスを再起動します。

設定が正常に再読み込みされたら、再度 psql コマンドで接続を試みてください。

ステップ4：PostgreSQLサーバー側のユーザー設定確認

pg_hba.conf の設定が正しく、パスワード認証方式が指定されているにも関わらず認証失敗する場合、問題はPostgreSQLのユーザー（ロール）自体の設定にある可能性があります。

1. スーパーユーザーでの接続:

ユーザー設定を確認・変更するには、通常スーパーユーザー権限が必要です。可能であれば、PostgreSQLのスーパーユーザー（デフォルトは postgres）で接続を試みてください。もしスーパーユーザーでの接続も認証失敗する場合は、そのスーパーユーザーのパスワード自体に問題があるか、スーパーユーザーに対する pg_hba.conf 設定に問題があるかのどちらかです。その場合は、まずスーパーユーザーのパスワードリセット（後述）を検討するか、データディレクトリ直下の pg_hba.conf をローカル接続で trust に一時的に変更してアクセス権を得るなどの方法をとる必要があります（ただし、後者は変更後に元に戻すのを忘れないように注意が必要です）。

2. ユーザー情報の確認:

スーパーユーザーで接続できたら、psql プロンプトで以下のコマンドを実行し、ユーザー一覧とその属性を確認します。

sql
\du

または、より詳細な情報をSQLで取得します。

sql
SELECT rolname, rolsuper, rolinherit, rolcreaterole, rolcreatedb, rolcanlogin, rolreplication, rolbypassrls, rolconnlimit, rolvaliduntil, rolconfig FROM pg_roles;

確認ポイント:

  • ユーザーの存在: 認証に失敗しているユーザー名がこのリストに存在しますか？ユーザー名の大文字小文字も一致していますか？
  • rolcanlogin 属性: 該当ユーザーの rolcanlogin が t (true) になっていますか？f (false) の場合、そのロールはログインできません。
  • パスワード設定の有無: \du コマンドの出力ではパスワード自体は見えませんが、ユーザーがパスワードを持っているかどうかの情報が含まれている場合があります（例えば、一部のバージョンや設定では、パスワードが設定されていれば Password valid until ... のような情報が表示されることがあります）。より確実なのは、次のパスワードリセット手順です。

3. パスワードのリセット:

該当ユーザーのパスワードが正しく設定されているか不明な場合、またはパスワードをリセットしたい場合は、スーパーユーザーで以下のコマンドを実行します。

sql
ALTER USER <ユーザー名> PASSWORD '<新しいパスワード>';

例:

sql
ALTER USER myuser PASSWORD 'mynewpassword';

パスワードをリセットしたら、新しいパスワードを使って再度接続を試みてください。

4. LOGIN 属性の付与:

もし \du コマンドで該当ユーザーに rolcanlogin 属性がない（f または表示されない）場合、以下のコマンドで LOGIN 属性を付与します。

sql
ALTER ROLE <ユーザー名> LOGIN;

例:

sql
ALTER ROLE myuser LOGIN;

その後、再度接続を試みてください。

ステップ5：クライアント側の設定確認

psql では接続できるのに、特定のアプリケーションやツールからだと「password authentication failed」になる場合、問題はそのクライアント側の設定にあります。

確認ポイント:

  • 接続情報: アプリケーションやツールの設定画面、設定ファイル、環境変数、またはソースコード中の接続文字列で、以下の情報が正しく設定されているか確認してください。
    • ホスト名/IPアドレス
    • ポート番号
    • データベース名
    • ユーザー名
    • パスワード
      これらの情報に、前後に不要な空白文字や改行コードなどが含まれていないかも確認してください。
  • 接続文字列の形式: 使用しているライブラリやフレームワークに応じた正しい接続文字列形式を使用していますか？（例: JDBC, Npgsql, SQLAlchemyなどでは形式が異なります）。
  • パスワードの取得方法: パスワードを環境変数から取得している場合、その環境変数は正しく設定されていますか？設定ファイルから読み込んでいる場合、ファイルパスや読み込みロジックは正しいですか？
  • クライアントライブラリ/ドライバのバージョン: 使用しているPostgreSQLクライアントライブラリやドライバのバージョンは、サーバーのPostgreSQLバージョンや認証方式（特に scram-sha-256）に対応していますか？もし古いバージョンを使用している場合、認証方式の不一致により認証失敗となることがあります。可能であれば、クライアントライブラリを最新バージョンにアップデートしてみてください。
  • ツールの設定: pgAdminなどのGUIツールを使用している場合、サーバー接続設定ダイアログで、ホスト、ポート、データベース、ユーザー名、パスワード、そして「SSL」などのオプションが正しく設定されているか確認してください。SSL設定がサーバーとクライアントで一致しない場合も認証問題となることがあります。

アクション: クライアント側の設定を徹底的に確認し、誤りがあれば修正します。特に、接続文字列や設定ファイルでのパスワードの記述には細心の注意を払ってください。ライブラリのバージョンが古い場合は、アップデートを検討します。

ステップ6：ネットワーク設定、ファイアウォール確認

「password authentication failed」エラーが出ているということは、TCP/IPレベルでの接続は成功しているはずですが、念のため確認しておく価値はあります。特にリモート接続の場合です。

確認ポイント:

  • サーバー側のファイアウォール: PostgreSQLがListenしているポート（デフォルト 5432）が、サーバー側のファイアウォールで、クライアントのIPアドレスからの接続に対して許可されていますか？
  • ネットワーク経路: クライアントからサーバーまでのネットワーク経路に、接続をブロックする機器（ルーター、VPN、プロキシなど）はありませんか？

確認方法:

クライアントからサーバーのPostgreSQLポートへの接続が可能か、telnet コマンドで確認します。

bash
telnet <サーバーのホスト名またはIPアドレス> <ポート番号>

例:

bash
telnet my.postgres.server 5432

  • 成功: ターミナルに「Connected to …」のようなメッセージが表示され、カーソルが点滅すればTCP/IP接続は成功しています。この場合はネットワークやファイアウォールが直接の原因ではありません。
  • 失敗: 「Connection refused」、「Connection timed out」、「No route to host」などのメッセージが表示される場合、TCP/IP接続自体ができていません。この場合は、サーバー側のファイアウォール設定、ネットワーク設定、あるいはPostgreSQLサーバーが指定されたポートでListenしていない (postgresql.conf の listen_addresses, port 設定、またはサーバーが起動していない) ことが原因として考えられます。

アクション: telnet で接続できない場合は、サーバー側のファイアウォール設定（iptables, firewalld, Windows Firewallなど）を確認し、PostgreSQLのポート（デフォルト 5432）を開放します。postgresql.conf の listen_addresses = '*' (またはクライアントのIPが含まれる設定) と port = 5432 (または使用しているポート番号) が正しく設定されており、PostgreSQLサーバーが稼働しているか確認します。

ステップ7：PostgreSQLサーバーのバージョンと認証方式の確認

PostgreSQLのバージョンによって、サポートされる認証方式やデフォルト設定が異なります。

確認ポイント:

  • サーバーのバージョン: 使用しているPostgreSQLサーバーのバージョンを確認します (psql で接続後 SELECT version();)。
  • サーバーのパスワード認証方式: postgresql.conf ファイルで password_encryption パラメータを確認します。これが scram-sha-256 になっている場合、サーバーはSCRAM-SHA-256方式でパスワードをハッシュ化し、認証時もこれを要求します。古いバージョンではデフォルトまたは明示的に md5 が設定されている場合があります。
  • クライアントの認証方式サポート: 使用しているクライアントライブラリやツールが、サーバーが要求する認証方式（特に scram-sha-256）に対応しているか確認します。古いバージョンのライブラリはSCRAM-SHA-256に対応していないことがあります。

アクション:

  • サーバー側が scram-sha-256 を使用しているのに、クライアント側が対応していない場合、以下のいずれかを検討します。
    • クライアントライブラリ/ツールをSCRAM-SHA-256に対応したバージョンにアップデートする。これが最も推奨される解決策です。
    • （非推奨）サーバー側の postgresql.conf で password_encryption = 'md5' に一時的に変更し、pg_ctl reload で反映させる。ただし、MD5はパスワードハッシュとして脆弱性が指摘されているため、これは一時的な措置とし、可能な限り早くクライアント側をアップデートすべきです。また、既存ユーザーのパスワードもMD5形式で格納されている必要があります。必要に応じて ALTER USER <ユーザー名> PASSWORD '<パスワード>'; で再設定すると、password_encryption で指定された形式でハッシュ化されます。
  • サーバー側が md5 を使用しており、クライアントもこれに対応しているはずなのにエラーが出る場合は、MD5ハッシュ化されたパスワード自体に問題があるか、pg_hba.conf の設定が原因である可能性が高いです。

ステップ8：サーバーログの詳細確認

PostgreSQLサーバーは、認証失敗を含む様々なイベントをログに出力します。ログファイルを確認することで、認証失敗が発生した正確な日時、接続元IPアドレス、試行されたユーザー名などの詳細情報を得ることができます。これは原因特定のための非常に強力な手がかりとなります。

1. ログファイルの場所特定:

postgresql.conf ファイルでログに関する設定を確認します。

  • log_destination: ログの出力先 (例: stderr, csvlog)
  • logging_collector: ログ収集を有効にするか (通常 on)
  • log_directory: ログファイルの出力先ディレクトリ
  • log_filename: ログファイルの命名規則 (例: postgresql-%Y-%m-%d_%H%M%S.log)

これらの設定から、ログファイルがどのディレクトリに、どのような名前で出力されているかを確認します。データディレクトリの log サブディレクトリにあることが多いです。

2. ログファイルの内容確認:

テキストエディタまたは grep コマンドなどでログファイルを開き、「password authentication failed」という文字列を含む行を探します。

例 (Linux):

bash
grep "password authentication failed" /var/lib/pgsql/data/log/postgresql-*.log

ログエントリは通常、タイムスタンプ、プロセスID、ユーザー名、データベース名、クライアントIPアドレス、エラーメッセージなどの情報を含んでいます。

例（ログ出力形式による）：

2023-10-27 10:30:00 UTC [1234]: [unknown]@[unknown] [5678]LOG: connection received: host=[クライアントIPアドレス] port=[クライアントポート]
2023-10-27 10:30:00 UTC [1234]: myuser@mydatabase [5678]FATAL: password authentication failed for user "myuser"
2023-10-27 10:30:00 UTC [1234]: myuser@mydatabase [5678]DETAIL: Password matches for user "myuser", but authentication method "scram-sha-256" failed.

（補足: ログの詳細度は postgresql.conf の log_min_messages や log_connections, log_disconnections, log_authentication_duration などの設定に依存します。トラブルシューティング中は詳細なログが出力されるように設定を一時的に変更すると役立つ場合があります。）

確認ポイント:

  • 接続元IPアドレス: ログに記録されているクライアントIPアドレスは、意図した接続元IPアドレスと一致していますか？
  • ユーザー名とデータベース名: エラーが発生しているユーザー名とデータベース名は正しいですか？
  • 試行された認証方式: ログの DETAIL 行などに、どの認証方式が試行されたか、またはどの段階で失敗したかの詳細が含まれている場合があります（例: “authentication method \”scram-sha-256\” failed”）。これは pg_hba.conf の設定やクライアントの対応状況を確認する上で重要な情報です。

アクション: ログの詳細情報を分析し、エラー発生時の状況（接続元、ユーザー、データベース、試行された認証方式）を正確に把握します。この情報に基づいて、pg_hba.conf やユーザー設定、クライアント設定のどこに問題がありそうか、より的確に判断します。

ステップ9：OSユーザーとPostgreSQLユーザー（Peer認証など）

pg_hba.conf で local 接続に peer 認証方式、またはリモート接続に ident 認証方式を指定している場合、PostgreSQLの認証はOSのユーザー情報に基づいて行われます。この場合、提供されるパスワードは無視されるか、そもそもパスワード認証自体が行われません。もしこれらの認証方式を意図せず使用している場合、「password authentication failed」とは少し異なる挙動になりますが、関連情報として確認しておきましょう。

  • Peer認証 (local): Unixドメインソケット経由での接続（ローカル接続）に使用され、クライアントを実行しているOSユーザー名と、接続しようとしているPostgreSQLユーザー名が一致している場合に認証成功とみなされます。
  • Ident認証 (host): TCP/IP接続に使用され、接続元のクライアントマシン上のidentdサーバーから接続元OSユーザー名を取得し、それがPostgreSQLユーザー名と一致するかで認証を行います。

確認ポイント:

  • pg_hba.conf で peer または ident 認証方式を使用していますか？
  • クライアントを実行しているOSのユーザー名は、接続しようとしているPostgreSQLユーザー名と一致していますか？

アクション:

  • もし peer や ident 認証を意図していない場合は、pg_hba.conf の該当エントリの認証方式を md5 や scram-sha-256 に変更します。
  • もしこれらの認証方式を意図している場合は、OSユーザー名とPostgreSQLユーザー名が一致しているか確認します。一致していない場合は、どちらかの名前を修正するか、別の認証方式を使用するように変更します。

ステップ10：その他の可能性の検討

これまでのステップで解決しない場合、稀なケースや複合的な原因が考えられます。

  • 複数のPostgreSQLインスタンス: サーバー上で複数のPostgreSQLインスタンスが異なるポートで稼働している場合、意図しないポート番号に接続しようとしていないか確認します。ps aux | grep postgres (Linux) やタスクマネージャー (Windows) などでPostgreSQLのプロセスを確認し、起動オプションで指定されているポート番号を確認します。
  • OSレベルでの権限問題: PostgreSQLサーバープロセスを実行しているOSユーザー（通常 postgres）が、データディレクトリや設定ファイル (pg_hba.conf, postgresql.conf) への適切な読み取り権限を持っていない場合、サーバーが正常に起動できないか、設定を読み込めずに認証処理に失敗する可能性があります（これは起動時のエラーになることが多いですが）。ファイルやディレクトリの権限設定を確認します。

予防策とベストプラクティス

「password authentication failed」エラーに悩まされないために、以下の予防策とベストプラクティスを実践することをお勧めします。

  1. 適切なパスワード管理:

    • PostgreSQLユーザーには推測されにくい強固なパスワードを設定します。
    • パスワードは安全な方法（パスワードマネージャーなど）で管理し、設定ファイルやソースコードに平文でハードコーディングするのを避けます。
    • 定期的にパスワードを変更することを検討します。

  2. ユーザーと権限の管理:

    • データベースにアクセスするユーザーは、必要最低限の権限のみを持つように設定します（最小権限の原則）。LOGIN 属性を持つユーザーは、実際に接続が必要なユーザーのみに限定します。
    • 不要になったユーザーアカウントは速やかに削除します。
    • postgres スーパーユーザーアカウントは、管理目的のみに使用し、通常のアプリケーション接続には使用しないようにします。また、postgres ユーザーには必ず強固なパスワードを設定します。

  3. pg_hba.conf の適切な設定:

    • trust 認証方式は、完全に信頼できる環境（例えば、開発環境のローカル接続のみ）以外では絶対に使用しません。
    • 必要な接続元アドレス、ユーザー、データベースの組み合わせに対してのみ接続を許可します。特に、リモートからの接続を許可する場合、アクセス元IPアドレス/範囲を厳密に指定し、0.0.0.0/0 や ::/0 のような広範な設定は避けます。
    • 認証方式は、scram-sha-256 のような強力な方式を使用します。古い md5 は非推奨です。
    • 設定変更後は、必ず pg_ctl reload またはサービスリロード/再起動で設定を反映させます。
    • pg_hba.conf ファイルは適切にバージョン管理することを検討します。

  4. ログ監視:

    • PostgreSQLサーバーのログ（特に認証失敗ログ）を継続的に監視します。これにより、不正なアクセス試行を早期に検出し、対応することができます。ログ集約システム（Fluentd, Logstashなど）や監視ツール（Zabbix, Prometheusなど）との連携を検討します。

  5. クライアントとサーバーのバージョン互換性:

    • PostgreSQLサーバーをバージョンアップする際は、使用しているクライアントライブラリやアプリケーションが新しいバージョンおよびデフォルト認証方式（特に scram-sha-256）に対応しているか確認します。

  6. ドキュメント化:

    • PostgreSQLサーバーの構成、ユーザーアカウント、パスワード、pg_hba.conf の設定、ファイアウォール設定などの重要な情報を正確にドキュメント化しておきます。これにより、トラブル発生時に迅速に情報を参照できます。

  7. テスト環境での確認:

    • 本番環境の設定を変更する前に、可能な限りテスト環境で変更内容の動作を確認します。

これらの対策を講じることで、「password authentication failed」エラーが発生するリスクを大幅に減らし、もし発生した場合でも迅速に原因を特定し解決できるようになります。

まとめ

PostgreSQLの「password authentication failed」エラーは、データベース運用において頻繁に遭遇する問題ですが、その原因は多岐にわたります。この記事では、エラーの基本的な意味から、パスワードの誤入力、ユーザー名・データベース名の誤り、pg_hba.conf の設定ミス、PostgreSQLユーザー設定、クライアント側の問題、バージョン間の違い、ネットワーク設定、そしてログの確認まで、様々な角度から原因と解決策を詳細に解説しました。

エラーが発生した際は、慌てずに本記事で紹介したトラブルシューティング手順を一つずつ、体系的に実行していくことが重要です。

  1. 基本的な情報の再確認: ユーザー名、パスワード、ホスト、ポート、データベース名が正確か。
  2. psqlでの接続テスト: 問題がサーバー側かクライアント側かを切り分ける。
  3. サーバー側の設定確認 (pg_hba.conf): 接続元、ユーザー、データベース、認証方式が正しく設定されているか。設定変更後はリロードを忘れずに。
  4. サーバー側のユーザー設定確認: ユーザーが存在し、LOGIN 権限があり、パスワードが正しく設定されているか。必要ならパスワードをリセット。
  5. クライアント側の設定確認: アプリケーションやツールの接続情報やライブラリのバージョンが正しいか。
  6. ネットワーク設定、ファイアウォール確認: TCP/IP接続が妨げられていないか。telnetで確認。
  7. バージョンと認証方式の確認: サーバーとクライアント間で認証方式（md5 vs scram-sha-256）に互換性があるか。
  8. サーバーログの詳細確認: ログファイルからエラーの発生状況（接続元、ユーザー、試行された認証方式など）を分析する。

これらの手順を踏むことで、ほとんどの「password authentication failed」エラーは解決できるはずです。

また、エラー発生後の対処だけでなく、予防策を講じることも同様に重要です。強固なパスワードの使用、適切な権限管理、pg_hba.conf のセキュアな設定、そして継続的なログ監視は、将来的な認証問題を未然に防ぐために非常に有効です。

データベースのトラブルシューティングは根気が必要ですが、原因を特定し、問題を解決できたときの達成感は大きいものです。この記事が、あなたがPostgreSQLの「password authentication failed」エラーを克服し、より安定したデータベース運用を実現するための一助となれば幸いです。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール