MySQL8から認証方式が変わったせいでSequelProからログインできなかった件

追記 どうやら Sequel Pro は MySQL8 にまだ対応しておらず、ログインできないだけではなくて DB を選択するとクラッシュします。詳しくは以下に書きました。

norikone.hatenablog.com


MySQL を 8 にアップグレードしたところ、Sequel Pro からログインできなくなってしまいました。この記事ではその原因と対処法を書きます。以下、そのエラーメッセージ。

Authentication plugin 'caching_sha2_password' cannot be loaded: dlopen(/usr/local/lib/plugin/caching_sha2_password.so, 2): image not found

公式によると、同じ原因で以下のようなエラーメッセージも発生するかもよとのことです。

Authentication plugin 'caching_sha2_password' is not supported
Warning: mysqli_connect(): The server requested authentication
method unknown to the client [caching_sha2_password]

問題の原因

どうやら MySQL 8 (正確には8.0.4) からデフォルトの認証方式が変わったみたいで、それが原因でこのエラーが出ているみたいです。変更についてのざっくりとした話は公式docのここに書いてあります。この変更の主な利点として、安全性や高速性があります。

MySQL の認証って所謂チャレンジレスポンス方式で、クライアントとサーバの2箇所で認証用のアルゴリズムがそれぞれ独立して動いていて、その結果を照合する感じになっています。なので、クライアントとサーバ間で認証アルゴリズムを揃えていないと上手く認証ができないわけです。

つまり、今回みたいなバージョンアップによってサーバ側の認証方式が変わった場合、クライアントもそれに合わせて認証方式を変更しなければいけません。これができていなかったというのが上のエラーの原因です(これは Sequel Pro に限らない話ですが)。

Sequel Pro はどうやら未だに 5.5 の libmysqlclient (MySQLサーバに接続するためのクライアントライブラリ)を使っていて、さらには互換性チェックのために 5.5 → 5.6 → 5.7 → 8.0 という形でステップを踏んでアップデートしなきゃいけないみたいです(ソース)。ということで、Sequel Pro 側がなんとかしてくれるまで割と時間がかかりそうです。

ちなみに新しい認証方式の動作シーケンスなどの具体的な話は、開発チームのブログに書いてありました。要は、ユーザのパスワードハッシュをキャッシュすることで初回以降の認証では暗号通信によるコストが発生しないようにしようということだと思いますが、まだ詳しくは理解していません。

暫定的な対処

2つの対処方法があります。 1つは、MySQL の設定を書き換えてデフォルトの認証方式を元に戻す方法です。 my.cnf に以下を書いてあげればOKです。

[mysqld]
default_authentication_plugin=mysql_native_password

もう1つの方法は、ユーザ単位で認証方式を変更するものです(認証方式はユーザ単位で設定されています)。 これは以下のように設定できます。

ALTER USER ユーザ名 IDENTIFIED WITH mysql_native_password BY 'パスワード';

ただ、公式にも書いてありますがこれらはあくまでも暫定的な対処なので、できれば安全でセキュアな新しい認証方式に移行したほうが良さそうですね。

おわり

ということで MySQL の認証方式について書きました。せっかくアップグレードしたのでこれから少しづつ遊んでみようと思います。新しい認証方式ではユーザのパスワードハッシュをサーバ側でキャッシュするということなので、それが攻撃点になって pass the hash 的に食らうようになりそうな気がしなくもないですが、おそらくその辺は大丈夫なようになっているのでしょう(方式の詳細を全く理解していないのでよくわかりません)。おわり。