MySQL 8.0的Public Key Retrival错误，毫无规律可言怎么破？

点击↑蓝字【DBAplus社群】并创建星标★

持续收获更多独家原创干货！

作者介绍

农行研发中心“数风云”团队，一支朝气蓬勃、快速成长的技术团队，始终致力于农行大数据、数据库和云计算等领域的应用实践与技术创新，探索数据赋能，勇攀数据云巅，为企业数字化转型和金融科技发展不断贡献力量。

一、背景介绍

近期笔者所在部门在使用MySQL时，经常会出现如下错误，且这个错误并不会一直出现，属于某种偶发性的错误：

笔者所在部门的连接数据库的方法有JDBC、JDBCTemplate、C3P0连接池和Druid连接池等技术，在这些连接实现方法上笔者都观察到出现过上述的错误。该错误有一定的特性，就是偶尔会出现该错误，该错误并不会一直出现，该错误的出现没有明显的规律。而且笔者发现，底层使用JDBC连接驱动的情况下，无论上层是采用何种数据源实现技术，笔者的部门都发现会报上述错误。

针对上述错误，在笔者所在部门的软硬件环境下，笔者对MySQL为何会产生这个问题、这个问题产生的条件、MySQL官方文档对这个问题的阐述、如何有效避免与解决这个问题等方面在本文进行了详细的分析与解释。希望能够帮助到真正遇到这个问题的DBA与开发人员。

二、环境介绍

1、实验构架

笔者所在部门使用的MySQL版本为8.0.18版本，MySQL使用组复制技术保证高可用，即MySQL Group Replication（MGR）。笔者复现问题以及实验的架构如下图所示：

图2.1  实验所采用的构架

本测试使用的MySQL MGR集群搭建在虚拟机之上，虚拟机的详细硬件配置如下表所示：

表2.1  详细硬件配置

为了充分测试各种类型的连接数据库的方式在笔者所在部门使用的MySQL上的表现，笔者分别测试JDBC、JDBCTemplate、C3P0以及Druid方式连接数据库，参与测试的软件版本如下表所示：

表2.2  参与测试的软件版本

三、问题报错展示

在使用JDBC连接时，可能会出现“Public Key Retrieval is not allowed”的错误，从错误的Java堆栈信息中可以看出，该错误是在JDBC与MySQL建立Connection对象时出现的，该错误的错误堆栈如下图所示：

图3.1  JDBC错误堆栈

在使用C3P0连接池时，也会出现“Public Key Retrieval is not allowed”的错误，从错误的Java堆栈信息中可以看出，该错误仍是在JDBC与MySQL建立Connection对象时出现，该错误会导致C3P0连接池在初始化时失败，该错误的错误堆栈如下图所示：

图3.2  C3P0错误堆栈

在使用Druid连接池时，也会出现“Public Key Retrieval is not allowed”的错误，与C3P0连接池一样，会导致Druid连接池在初始化时失败，该错误的错误堆栈如下图所示：

图3.3  Druid错误堆栈

四、问题分析

笔者在查阅了网上关于“Public Key Retrieval is not allowed”错误的资料后，发现大多数网上关于该问题的博文对该问题的解释都存在一定的纰漏。首先需要明确的是出现该问题的时候，MySQL配置的密码认证插件为如下两种：

• sha256_password

• caching_sha2_password

值得注意的是，如果使用“mysql_native_password”密码认证插件，不会出现“Public Key Retrieval is not allowed”错误。MySQL配置的密码认证方式可以通过如下命令进行查看。

接着笔者来详细分析“Public Key Retrieval is not allowed”错误产生的原因。首先MySQL 8.0默认推荐使用“sha256_password”和“caching_sha2_password”这两种认证插件。只有较老的MySQL版本仍然会使用“mysql_native_password”。

根据MySQL提供的官方文档（https://dev.mysql.com/doc/refman/8.0/en/caching-sha2-pluggable-authentication.html），这两种插件都是使用SHA256算法来对密码进行保护。这些插件的具体执行流程如下：

1. 检查客户端是否禁用SSL/TLS加密传输；

2. 如果客户端未禁用SSL/TLS加密传输，则客户端在进行认证时的认证报文（传输用户名和密码的报文）是使用TLS进行传输的，两种插件认为认证报文传输安全，不进行任何其他操作；

3. 如果客户端禁用SSL/TLS加密传输，则客户端在进行认证时的认证报文（传输用户名和密码的报文）是使用明文进行传输的，两种插件认为认证报文传输不安全，会单独对明文报文中的密码使用RSA加密方式进行加密。

1、启用SSL/TLS加密传输的客户端认证流程

如上述流程所述，当客户端未禁用SSL/TLS加密传输时，通过Wireshark等抓包工具可以观察到整个客户端与MySQL服务端交互的过程都被TLS协议加密保护了。如下图所示：

图4.1  启用TLS协议MySQL传输报文

虽然会产生登录的明文报文，但是该明文报文中的用户信息为空，真正的用户信息在TLS握手阶段后的密文中。如下图所示：

图4.2  启用TLS协议MySQL登录数据包详情

2、禁用SSL/TLS加密传输的客户端认证流程

如上述流程所述，当客户端禁用SSL/TLS加密传输时（比如JDBC连接串设置useSSL=false参数），用户的登录信息会在明文中进行传输，如下图所示：

图4.3  禁用TLS协议MySQL传输报文

明文传输密码存在安全问题，此时，两种插件会尝试使用RSA加密（RSA encryption）方法对明文报文中的密码部分进行加密，加密后的密码部分如下图所示：

图4.4  启用TLS协议MySQL登录数据包详情

五、解决方案

根据前面的分析，导致“Public Key Retrieval is not allowed”主要是由于当禁用SSL/TLS协议传输后，客户端会使用服务器的公钥进行传输，默认情况下客户端不会主动去找服务器拿公钥，此时就会出现上述错误。

经过查阅官方文档，出现Public Key Retrieval的场景可以概括为在禁用SSL/TLS协议传输切当前用户在服务器端没有登录缓存的情况下，客户端没有办法拿到服务器的公钥。具体的场景如下：

1. 新建数据库用户，首次登录；

2. 数据库的用户名、密码发生改变后登录；

3. 服务器端调用FLUSH PRIVELEGES指令刷新服务器缓存。

针对上述错误，有如下的解决方案：

1. 在条件允许的情况下，不要禁用SSL/TLS协议，即不要在CLI客户端使用--ssl-mode=disabled，或在JDBC连接串中加入useSSL=false；

2. 如果必须禁用SSL/TLS协议，则可以尝试使用CLI客户端登录一次MySQL数据库制造登录缓存；

3. 如果必须禁用SSL/TLS协议，则可以通过增加如下参数允许客户端获得服务器的公钥：

• 在JDBC连接串中加入allowPublicKeyRetrieval=true参数；

• 在CLI客户端连接时加入--get-server-public-key参数；

• 在CLI客户端连接时加入--server-public-key-path=file_name参数，指定存放在本地的公钥文件。