Java应用出现 Public Key Retrieval is not allowed 报错的常见原因和解决方法

就是喜欢美食 發表於 2025-5-12 09:45:00

Java应用出现 Public Key Retrieval is not allowed 报错的常见原因和解决方法

<h1 data-tool="mdnice编辑器">问题现象</h1>
Java 应用在运行过程中突然报<code>java.sql.SQLNonTransientConnectionException: Public Key Retrieval is not allowed</code>错误。
开发童鞋表示不理解，毕竟应用没做任何变更，为什么会突然出现这个错误？
<pre data-tool="mdnice编辑器"><span data-cacheurl="" data-remoteid="" data-lazy-bgimg="https://mmbiz.qpic.cn/mmbiz_svg/BO1qQiajiacVll2lZZ7QEHpaGp010vNgdTZpC499x6fDYD6IXjhHscicX7TJgibQIzLdFWHKwTys7BC9a67BBh02ODoU0EeWoEDp/640?wx_fmt=svg&from=appmsg" data-fail="0"><code>2025-03-31 08:31:11 - create connection SQLException, url: jdbc:mysql://10.0.1.86:3306/information_schema?useSSL=false, errorCode 0, state 08001 java.sql.SQLNonTransientConnectionException: Public Key Retrieval is not allowed         at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:110)         at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:122)         at com.mysql.cj.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:828)         at com.mysql.cj.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:448)         at com.mysql.cj.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:241)         at com.mysql.cj.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:198)         at com.alibaba.druid.pool.DruidAbstractDataSource.createPhysicalConnection(DruidAbstractDataSource.java:1682)         at com.alibaba.druid.pool.DruidAbstractDataSource.createPhysicalConnection(DruidAbstractDataSource.java:1803)         at com.alibaba.druid.pool.DruidDataSource$CreateConnectionThread.run(DruidDataSource.java:2914)         ... </code></pre>
<h1 data-tool="mdnice编辑器">问题原因</h1>
用户使用的密码认证插件是 caching_sha2_password 且 JDBC 连接串中指定了<code>useSSL=false</code>。
当碰到以下场景，就会出现上述报错：
<ol class="list-paddingleft-1">
<li>第一次连接时。</li>
<li>数据库实例发生了重启。</li>
<li>服务端执行了 FLUSH PRIVILEGES 操作。</li>
</ol>
<h1 data-tool="mdnice编辑器">解决方法</h1>
解决方法有以下几种：
方案 1
将用户的密码认证插件调整为 mysql_native_password。不推荐该方法，因为 MySQL 9.0 移除了 mysql_native_password。
<pre data-tool="mdnice编辑器"><span data-cacheurl="" data-remoteid="" data-lazy-bgimg="https://mmbiz.qpic.cn/mmbiz_svg/BO1qQiajiacVll2lZZ7QEHpaGp010vNgdTZpC499x6fDYD6IXjhHscicX7TJgibQIzLdFWHKwTys7BC9a67BBh02ODoU0EeWoEDp/640?wx_fmt=svg&from=appmsg" data-fail="0"><code>ALTER USER 'u1'@'%' IDENTIFIED WITH mysql_native_password BY 'MySQL@2025'; </code></pre>
方案 2
在 JDBC 连接串中设置<code>useSSL=true</code>。推荐该方法，但开启 SSL 会有一定的性能开销。
如果既不想开启 SSL，又想避免 Public Key Retrieval is not allowed 错误，以下是两个可选的解决方案：
方案 3
在 JDBC 连接串中添加<code>allowPublicKeyRetrieval=true</code>。
该方法会自动从 MySQL 服务端获取 RSA 公钥，但这种方法有一定的安全风险，可能会受到中间人攻击。攻击者可以伪造 RSA 公钥，窃取用户密码。
方案 4
在 JDBC 连接串中指定<code>serverRSAPublicKeyFile</code>。
该方法需要将方案 3 中的公钥内容写到应用侧的一个本地文件中，具体步骤如下：
<ul class="list-paddingleft-1">
<li>
通过<code>show status like 'Caching_sha2_password_rsa_public_key'</code>命令或者从参数 caching_sha2_password_public_key_path（默认是 public_key.pem）指定的文件中获取公钥内容。
</li>
<li>
将公钥内容保存到应用侧的一个本地文件中。
</li>
<li>
在 JDBC 连接串中指定该公钥文件路径。如，
</li>
</ul>
<pre data-tool="mdnice编辑器"><span data-cacheurl="" data-remoteid="" data-lazy-bgimg="https://mmbiz.qpic.cn/mmbiz_svg/BO1qQiajiacVll2lZZ7QEHpaGp010vNgdTZpC499x6fDYD6IXjhHscicX7TJgibQIzLdFWHKwTys7BC9a67BBh02ODoU0EeWoEDp/640?wx_fmt=svg&from=appmsg" data-fail="0"><code>JDBC_URL = "jdbc:mysql://10.0.1.86:3306/information_schema?useSSL=false&serverRSAPublicKeyFile=/usr/local/caching_sha2_password_public_key.pem" </code></pre>
相较于方案 3，方案 4 无疑会更安全，但在高可用环境下并不适用，因为主从节点的公钥内容通常不同。一旦发生主从切换，JDBC 客户端在重新连接新的主节点时，就可能因公钥不一致而触发 Public Key Retrieval is not allowed 错误。除非在部署时显式配置，让主从节点使用相同的公钥，才能避免该问题。
<h2 data-tool="mdnice编辑器">四种方案的优缺点对比</h2>
 
<table>
<thead>
<tr><th>方案</th><th>安全等级</th><th>适用场景</th><th>备注</th></tr>

</thead>
<tbody>
<tr>
<td>SSL 加密连接 (useSSL=true)</td>
<td>★★★★★</td>
<td>所有生产环境</td>
<td>最安全方案，推荐优先使用</td>

</tr>
<tr>
<td>手动配置 RSA 公钥 (serverRSAPublicKeyFile)</td>
<td>★★★★☆</td>
<td>禁用 SSL 的生产环境</td>
<td>需维护公钥文件</td>

</tr>
<tr>
<td>自动获取 RSA 公钥 (allowPublicKeyRetrieval=true)</td>
<td>★★☆☆☆</td>
<td>可信内网环境</td>
<td>存在中间人攻击风险</td>

</tr>
<tr>
<td>更改认证插件</td>
<td>★☆☆☆☆</td>
<td>不推荐</td>
<td>兼容性差，安全性低</td>

</tr>

</tbody>

</table>
<h1 data-tool="mdnice编辑器">根因分析</h1>
简单来说，caching_sha2_password 插件为了加快认证过程，在服务端维护了一个密码哈希缓存。当客户端发起连接时：
<ul class="list-paddingleft-1">
<li>如果用户的密码哈希已经被缓存，服务端可以直接验证，无需客户端发送明文密码进行验证。</li>
<li>如果缓存中没有该用户的密码哈希（比如第一次连接时，除此之外，数据库重启或执行 FLUSH PRIVILEGES，还会清除密码哈希缓存），则客户端需要发送明文密码进行认证。</li>

</ul>
在发送明文密码时，出于安全考虑，MySQL 要求：
<ul class="list-paddingleft-1">
<li>要么客户端和服务端之间建立 SSL 加密连接。</li>
<li>要么客户端允许通过服务端公钥加密明文密码。</li>

</ul>
如果两者都不满足，就会抛出 Public Key Retrieval is not allowed 错误。
<h1 data-tool="mdnice编辑器">caching_sha2_password 的认证交互流程</h1>
以下是客户端与服务端使用 caching_sha2_password 插件进行身份认证时的完整交互流程：
<img src="https://img2024.cnblogs.com/blog/576154/202505/576154-20250512094354040-1466809290.png" alt="" loading="lazy">
 
 
具体实现细节如下：
<ol class="list-paddingleft-1">
<li>
MySQL 服务端收到客户端的请求后，会生成一个长度为 21 字节的随机数。

</li>
<li>
MySQL 服务端给客户端发送一个握手包（handshake packet）。
该握手包是 MySQL 服务端与客户端建立连接时发送的第一个数据包，包的内容如下：
握手包的构造和发送是在<code>send_server_handshake_packet</code>函数中实现的。

</li>
<ol class="list-paddingleft-1">
<li>
协议版本。

</li>
<li>
服务端版本。

</li>
<li>
线程 ID。

</li>
<li>
随机数的第一部分。

</li>
<li>
服务端能力标志（低16位）。

</li>
<li>
默认字符集编号。

</li>
<li>
服务端状态标志。

</li>
<li>
服务端能力标志（高16位）。

</li>
<li>
随机数的的长度。

</li>
<li>
保留字段。

</li>
<li>
随机数的第二部分。

</li>
<li>
默认的密码认证插件名称。
在 MySQL 8.4 之前，默认的密码认证插件由 default_authentication_plugin 参数决定。在 MySQL 5.7 中，该参数的默认值为 mysql_native_password，在 MySQL 8.0 中，该参数的默认值为 caching_sha2_password。在 MySQL 8.4 中，移除了这个参数，默认的密码认证插件硬编码为 caching_sha2_password。

</li>

</ol>
<li>
客户端在接收到服务端的握手包后，会根据握手包中的密码认证插件进行身份验证。对于 caching_sha2_password 插件，客户端将基于以下公式构造一个 <code>scramble_response</code>，然后调用<code>prep_client_reply_packet</code>构造握手包发送给服务端。公式中的 random 是服务端在握手包中发送的随机数。
<pre><span data-cacheurl="" data-remoteid="" data-lazy-bgimg="https://mmbiz.qpic.cn/mmbiz_svg/BO1qQiajiacVll2lZZ7QEHpaGp010vNgdTZpC499x6fDYD6IXjhHscicX7TJgibQIzLdFWHKwTys7BC9a67BBh02ODoU0EeWoEDp/640?wx_fmt=svg&from=appmsg" data-fail="0"><code>scramble_response = XOR(SHA256(password), SHA256(SHA256(SHA256(password)) + random) </code></pre>
</li>
<li>
服务端调用<code>parse_client_handshake_packet</code>解析客户端返回的握手包，解析出来的内容包括用户名、密码（不是明文密码，是 scramble_response）、库名。
</li>
<li>
基于用户名和客户端 IP 从<code>ACL</code>缓存中找到用户对应的认证信息，包括密码认证插件和密码哈希值。
</li>
<li>
调用<code>Caching_sha2_password::fast_authenticate</code>进行快速验证。快速验证的逻辑如下：
</li>
<ul class="list-paddingleft-1">
<li>
首先基于用户名和主机名构造一个 authorization_id。
</li>
<li>
判断 authorization_id 是否在 m_cache 存在。m_cache 即密码哈希缓存，是 caching_sha2_password 中的关键组件，它的底层实现是一个哈希表。该哈希表的键是 authorization_id，值是一个二维数组，用来存储新旧两个密码哈希值（从 MySQL 8.0 开始，一个用户可以设置两个密码），存储的值是对密码进行两次 SHA-256 哈希计算的结果，即<code>SHA256(SHA256(password)</code>。
</li>
<li>
如果存在，则通过以下步骤验证密码是否正确。
<pre><span data-cacheurl="" data-remoteid="" data-lazy-bgimg="https://mmbiz.qpic.cn/mmbiz_svg/BO1qQiajiacVll2lZZ7QEHpaGp010vNgdTZpC499x6fDYD6IXjhHscicX7TJgibQIzLdFWHKwTys7BC9a67BBh02ODoU0EeWoEDp/640?wx_fmt=svg&from=appmsg" data-fail="0"><code>SHA2(m_known, rnd) => scramble_stage1 XOR(scramble, scramble_stage1) => digest_stage1 SHA2(digest_stage1) => digest_stage2 m_known == digest_stage2 </code></pre>
其中，m_known 是 m_cache 中存储的密码哈希值，即 SHA256(SHA256(password)，rnd 是服务端发送给客户端的随机数（random），scramble 是客户端返回给服务端的 scramble_response。
最后，将 m_known 与 digest_stage2 进行比较，如果相等，则意味着密码正确。这个时候，服务端会给客户端发送一个<code>fast_auth_success</code>包。
</li>
<li>
如果 authorization_id 在 m_cache 中不存在，或者存在但不匹配，则意味着快速验证失败，这个时候，服务端会给客户端发送一个<code>perform_full_authentication</code>包，要求客户端发送密码进行身份验证。
</li>
</ul>
<li>
客户端收到服务端发送的<code>perform_full_authentication</code>包后：
</li>
<ul class="list-paddingleft-1">
<li>
如果连接是安全的（即开启了 SSL），则会向客户端发送明文密码。
</li>
<li>
如果连接不是安全的（即没有开启 SSL，一般是因为客户端显式指定了<code>--ssl-mode=DISABLED</code>），则会调用 rsa_init() 初始化 RSA 公钥，这个公钥是 mysql 客户端参数 server-public-key-path 指定的。如果没指定，则看 mysql 客户端参数中是否指定了get-server-public-key。
如果既没指定 server-public-key-path，又没指定 get-server-public-key，则 mysql 客户端会提示<code>ERROR 2061 (HY000): Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection.</code>错误。
JDBC 中的处理逻辑类似，对于非 SSL 连接，如果既没指定 serverRSAPublicKeyFile，又没指定allowPublicKeyRetrieval，则会提示<code>Public Key Retrieval is not allowed</code>错误，具体的实现细节可参考 CachingSha2PasswordPlugin.java 中的 nextAuthenticationStep 方法。
如果指定了 get-server-public-key，则客户端会向服务端发送一个<code>request_public_key</code>包。
</li>
</ul>
<li>
服务端收到客户端发送的<code>request_public_key</code>包后，会将 RSA 公钥发送给客户端。
</li>
<li>
客户端收到 RSA 公钥后，首先会将密码和服务端之前发送的随机数进行异或运算，然后使用 RSA 公钥对异或后的结果进行加密，最后将加密后的密文发送给服务端。
</li>
<li>
服务端收到加密后的密文后，会调用 decrypt_RSA_private_key 进行解密，获取明文密码。
</li>
<li>
服务端 Caching_sha2_password::authenticate 验证密码是否正确。验证的逻辑如下：
</li>
<ul class="list-paddingleft-1">
<li>
从 mysql.user 表 authentication_string 字段中提取迭代次数和盐值。
对于 caching_sha2_password，authentication_string 的格式如下：
<pre><span data-cacheurl="" data-remoteid="" data-lazy-bgimg="https://mmbiz.qpic.cn/mmbiz_svg/BO1qQiajiacVll2lZZ7QEHpaGp010vNgdTZpC499x6fDYD6IXjhHscicX7TJgibQIzLdFWHKwTys7BC9a67BBh02ODoU0EeWoEDp/640?wx_fmt=svg&from=appmsg" data-fail="0"><code>分隔符[摘要类型]分隔符[迭代次数]分隔符[盐值][哈希摘要] </code></pre>
其中，分隔符默认是 $，摘要类型是单个字母，A 表示使用 SHA256 算法，迭代次数是 3 位十六进制字符串，默认是 005，乘以 ITERATION_MULTIPLIER（默认是 1000），即为实际迭代次数（默认是 5000 次）。盐值是一个长度为 20 的随机字符串，剩下的字符串即为哈希摘要，长度为 43 字节。
</li>
<li>
基于提取的迭代次数、盐值和明文密码生成一个哈希摘要。
</li>
<li>
判断提取的哈希摘要和生成的哈希摘要是否相等，如果相等，则意味着密码正确，否则是错误的。
</li>
</ul>
</ol>
<h1 data-tool="mdnice编辑器">参考资料</h1>
<ol class="list-paddingleft-1">
<li>
Protocol::HandshakeV10：https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_connection_phase_packets_protocol_handshake_v10.html
</li>
<li>
Caching_sha2_password information：https://dev.mysql.com/doc/dev/mysql-server/latest/page_caching_sha2_authentication_exchanges.html
</li>
<li>
WL#9591: Caching sha2 authentication plugin：https://dev.mysql.com/worklog/task/?id=9591
</li>
</ol> 
来源：https://www.cnblogs.com/ivictor/p/18872158

頁: [1]

琼殿技术论坛's Archiver

Java应用出现 Public Key Retrieval is not allowed 报错的常见原因和解决方法