◀ 7.

MySQL ERROR 1698|ソケット認証・OSユーザー・接続経路の確認

▶

ERROR 1698の調査では、サーバー製品/版・接続経路・選択されるアカウント・認証方式を確認します。auth_socketが原因となることはありますが、OSやaptというだけで決めつけず、rootの認証変更や権限拡大に進まないでください。

接続経路とOSユーザー、DBアカウントを分けてソケット認証を調べる図

接続経路・OSユーザー・DBアカウントを分ける

  1. どのホスト/コンテナのMySQLか、製品と版を確認する。localhostが別コンテナを指すと推測しない。
  2. UnixソケットとTCPを区別し、アプリの実行OSユーザーも確認する。CLIで成功してもWeb/FPM等と同じ条件ではない。
  3. 認証に成功した許可済み接続ではUSER()とCURRENT_USER()を比較する。前者は接続時のユーザー/接続元、後者は認証に使われたアカウントで、必ずしも一致しない。
  4. mysql.userの参照は管理権限がある場合だけ行う。pluginを確認するためにauthentication_string全体を出力したり、結果を公開したりしない。
SELECT VERSION(), USER(), CURRENT_USER();
-- Authorized administrator only; do not publish account information.
SELECT User, Host, plugin FROM mysql.user WHERE User = 'root';

認証が拒否された接続ではこれらのSQLを実行できません。別の承認済み管理接続を使い、sudoや新しい管理者アカウントの作成を一般的な回避策にしないでください。

一次資料: MySQLのauth_socketとOS名の対応、アカウント照合、旧mysql_native_passwordの扱い、MariaDBのunix_socket。

この記事の要点
  • ERROR 1698は認証拒否。auth_socket等の認証方式と実際の接続条件を確認し、番号だけで原因を断定しない
  • 配布元/導入方法/移行履歴で認証設定は異なる。MySQLのauth_socketとMariaDBのunix_socketを区別する
  • 管理接続: sudo mysqlはOS/DB双方で許可された管理者が、接続先と方式を確認して使う
  • パスワードでログインしたいなら、root の認証方式を変えるより、アプリ用ユーザーを別に作るのが安全
  • 現在の認証方式は SELECT user, host, plugin FROM mysql.user; で確認できる

エラー内容

下はソケット認証の条件が合わず拒否された場合のエラー例です。-pで入力した値が実際に検証されるかは選択された認証方式によるため、「パスワードは正しい」と番号だけで判断しません。

ERROR 1698 (28000): Access denied for user 'root'@'localhost'

phpMyAdminやアプリでも接続経路/実行OSユーザー/ドライバ設定を照合します。別プロセスがCLIと同じ資格で接続するとは限らず、rootをアプリに設定して回避しません。

認証方式と接続経路を確認する

MySQLはUserとHostを組み合わせたアカウントごとに認証方式を持ちます。導入元/版/既存データによって初期設定は異なります。MySQLのauth_socketとMariaDBのunix_socketは別製品の機能なので、名前やALTER USER構文を混ぜません。

MySQLのauth_socketはUnixソケットのOS資格情報を確認します。OS名がDB名と一致する場合だけでなく、authentication_stringで別のOS名に対応付ける構成もあります。TCP/IPではこのソケット認証は使えません。DB名や入力パスワードだけを見て判定しないでください。

エラー主な原因
ERROR 1698 (28000)ソケット認証の条件不一致等。製品/プラグイン/OS資格情報と接続方式を照合
ERROR 1045 (28000)パスワードの誤り、ユーザーやホストの指定違い、権限不足

パスワードの入力ミスであれば通常は 1045 になります。1698 が出る場合は、まず認証方式を疑ってください。

対処法 1: 許可された管理接続で確認する

下のsudoはOS管理権限を使う旧例です。承認済みの管理者が実行先/ソケット/オプションファイルを確認して使い、一般利用者の権限昇格やDB権限の取得手順にはしません。rootのソケット認証が想定どおり設定されていなければ成功を保証しません。

sudo mysql
# または
sudo mysql -u root -p

純粋なauth_socket認証では入力パスワードを検証しないため、-pの有無だけで方式を判定しません。OS管理権限はDB管理へつながり得るので、利用者・実行記録・保守経路を管理します。

対処法 2: 専用アカウントと最小権限を確認する

アプリには用途を限定した既存の専用アカウントを確認します。新規作成が必要でも承認済みの別作業です。下は作成とGRANT ALLを行う旧例で、mydbというDBだけに限定しても必要以上のDDL権限等を含み得ます。そのまま実行せず、接続元と実際の操作に必要な最小権限を設計してください。

CREATE USER 'appuser'@'localhost' IDENTIFIED BY '強力なパスワード';
GRANT ALL PRIVILEGES ON mydb.* TO 'appuser'@'localhost';

phpMyAdminを使うだけで全DB権限やWITH GRANT OPTIONが必要になるわけではありません。管理対象と作業を限定し、アプリ実行用とスキーマ管理用を分けます。接続エラーを消すために権限を一律拡大しません。

旧例: rootの認証方式を変更する操作

下のALTER USERはrootの認証/資格情報を変える旧例で、通常の診断では実行しません。 保守接続の喪失、利用ドライバ/TLS、既存スクリプトへの影響を確認する別計画が必要です。MySQL 8.0のcaching_sha2_password等、対象製品/版とクライアント対応を照合してください。

ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY '新しいパスワード';

古い解説記事では mysql_native_password を指定する例が多く見られますが、このプラグインは MySQL 8.0.34 で非推奨になり、8.4 では既定で無効、9.0 で削除されています(2026 年時点)。古いクライアントのために認証を弱める初手にはせず、ドライバ更新と対応方式を検証してください。

下はMariaDBの別構文の旧例です。MySQLへは実行できず、全MariaDBが同じroot設定とも限りません。認証方式やパスワードの変更例なので、製品/版と既存の認証条件を確認するまで実行しません。

ALTER USER 'root'@'localhost' IDENTIFIED VIA unix_socket OR mysql_native_password USING PASSWORD('新しいパスワード');

なお、root をパスワード認証に変えると、sudo mysql だけではログインできなくなり、OS の保守スクリプトが root でのソケット接続を前提にしている場合に影響が出ることがあります。対処法 2 で済むなら、そちらを優先してください。

確認方法

各ユーザーの認証方式は次の SQL で確認できます。

SELECT user, host, plugin FROM mysql.user;
+------------------+-----------+-----------------------+
| user             | host      | plugin                |
+------------------+-----------+-----------------------+
| root             | localhost | auth_socket           |
| appuser          | localhost | caching_sha2_password |
+------------------+-----------+-----------------------+

pluginがauth_socketでもsudoだけが可能な接続手段とは限らず、許可されたOSユーザーとの対応付けを確認します。変更が別途承認された場合は既存の管理接続を閉じる前に新しい接続と必要権限を検証し、ロックアウトを防ぎます。

よくある質問

インストール直後で root のパスワードを設定した覚えがない

導入元と初期化方式、既存データ/移行の有無を確認します。設定した覚えがないことだけで空パスワードと判断せず、許可された運用担当へ確認してください。mysql_secure_installationも診断ではなく設定変更を伴うので、無条件に実行しません。

Docker の MySQL でも出る?

Dockerでもイメージ/初期化設定/既存データ/後のALTER USER次第です。環境変数MYSQL_ROOT_PASSWORDの現在値だけで、既存DBの認証方式や実際のパスワードを保証できません。1698を見たら実際の接続先とプラグインを確認し、DBボリュームを削除して初期化し直す手順にはしません。

関連

ほかの症状はMySQLエラー一覧の子ページから選んでください。ホスト遮断1129、期限切れ1820/1862とは条件を分けて調べます。

子ページ

子ページはありません

同階層のページ
  1. 1071 Specified key was too long; max key length is 767 bytes
  2. ERROR 1063 (42000): Incorrect column specifier for column '~'
  3. mysqld: Can't change dir to '...\MySQL\MySQL Server X.X\data\' (OS errno 2 - No such file or directory)
  4. Install/Remove of the Service Denied!
  5. Datetime 型が NULL に見える
  6. Warning: World-writable config file '/etc/mysql/my.cnf' is ignored
  7. ERROR 1698 (28000): Access denied for user 'root'@'localhost'
  8. Exception: Wrong MySQL configuration
  9. [Warning] TIMESTAMP with implicit DEFAULT value is deprecated.
  10. ERROR 1820 (HY000): You must reset your password using ALTER USER statement before executing this statement.
  11. ERROR 1819 (HY000): Your password does not satisfy the current policy requirements
  12. Incorrect column specifier for column 'カラム名'
  13. BLOB/TEXT column 'description' used in key specification without a key length
  14. ERROR: /bin/sh: mysql_config: コマンドが見つかりません
  15. Host '...' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts'
  16. CSVエクスポート時に「ERROR 1045 (28000): Access denied for user 'username'@'localhost'」エラーが表示される
  17. Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT
  18. SQLSTATE[22007]: Invalid datetime format: 1366 Incorrect string value: ~

最近更新/作成されたページ