MySQL 8.0连接报错Public Key Retrieval is not allowed的排查与解决

你在DBeaver里高高兴兴准备连一个MySQL 8.0实例结果连接测试还没跑完直接弹出一句红彤彤的Public Key Retrieval is not allowed第一反应是不是“我密码错了”不少人在这里卡了一个下午改密码、重启服务、卸载重装折腾一圈下来还是同一个报错。其实这个错误跟密码正确性没有半点关系它是MySQL 8.0默认认证插件和客户端安全策略之间的一次“规矩冲突”。搞懂这一句话问题就解决了一半。这篇文章我打算把这个报错彻底拆开先说底层原理再给几套不同的解决办法从DBeaver图形界面到JDBC URL参数全走一遍最后附上我平时排查这个问题的顺序能帮你少踩几个坑。1. 错误产生的底层原理为什么客户端要拿公钥1.1 MySQL 8.0默认认证方式变了MySQL 8.0发布之后默认的认证插件从原来的mysql_native_password换成了caching_sha2_password。这个改动本意是好的因为caching_sha2_password使用SHA-256算法做密码哈希安全性比老的native password方案高了一个档次。问题在于新插件在“非SSL连接”下验证用户身份时需要一个额外的步骤客户端必须先把密码用RSA公钥加密再发给服务器校验。这个RSA公钥哪来的一个是客户端提前在服务器上拿到并配置好证书另一个就是连接过程中向服务器动态请求。Public Key Retrieval is not allowed这个报错恰好就是第二种路径被拦截了。默认情况下JDBC驱动以及基于JDBC的DBeaver不允许客户端向服务器索取RSA公钥因为从服务器动态拿公钥这件事理论上存在被中间人攻击替换公钥的风险。于是客户端在认证阶段发现“既没有自带公钥又不允许现场拿”直接放弃连接抛出错误。用生活里的话说服务器要求你“把密码锁进保险箱再递过来”但你手里既没有钥匙也被告知“不能向对方要钥匙”那这个密码就根本没法安全地送出去。1.2 DBeaver默认配置踩中了这个雷DBeaver本身是纯JDBC客户端底层的驱动属性会直接透传到MySQL Connector/J。在DBeaver里新建MySQL连接时驱动属性中allowPublicKeyRetrieval默认值是falseuseSSL默认也是false。这两个参数凑在一起就形成了一个非常微妙的局面因为useSSLfalse客户端走的是明文TCP通道密码必须依赖RSA公钥加密来保护但allowPublicKeyRetrievalfalse又禁止了客户端向服务器要公钥。于是客户端陷入死局——这就是为什么你明明看到DBeaver的“连接设置”里什么都是对的密码也没输错却始终连不上的根本原因。所以解决的方向就清晰了要么允许客户端向服务器拿公钥要么换个不需要公钥的认证方式要么干脆把传输通道提升为SSL。下面每种方案都是围绕这三个方向展开的。1.3 为什么老项目没这个毛病用过MySQL 5.7甚至更早版本的人应该记得以前连数据库从来没听说什么“Public Key Retrieval”。因为老版本的默认认证插件是mysql_native_password它的验证流程是客户端直接发送密码哈希不需要公钥加密过程自然不涉及公钥检索这个概念。MySQL 8.0把默认插件切换成caching_sha2_password之后所有“习惯老规矩”的客户端工具都开始陆续报错。这也是为什么这个错误在网上铺天盖地几乎全是围绕MySQL 8.0的讨论。明白了这一点你在网上搜解决方案时就不会被各种“重装大法”带偏了。2. 方案一在DBeaver驱动属性里修改参数2.1 最快能落地的操作路径DBeaver提供了图形化修改驱动属性的入口大多数开发环境下的临时连接用这个方案就够了。具体操作如下在DBeaver左侧“数据库导航器”里右键点击目标连接选择“编辑连接”。在弹出的连接设置窗口中找到“连接设置”分类下的“驱动属性”页签。在属性列表里查找allowPublicKeyRetrieval。如果列表里没有这一项点击“添加新属性”手动输入。将该参数的值改为true。点击“确定”保存再重新执行“测试连接”。这里有个细节DBeaver不同版本界面文字略有区别个别版本中这项属性的显示名称是Allow Public Key Retrieval带空格且首字母大写但底层写入的键名始终是驼峰式的allowPublicKeyRetrieval。如果界面上有下拉选项直接选如果只能用“添加属性”的方式键名务必一字不差。2.2 设置完依然报错怎么办我遇到过不少用户反馈“明明设了true怎么还报错”这种情况通常是下面几个原因第一设置错了连接。DBeaver里可以同时存在多个连接配置你改的可能是A连接测试的却是B连接。确认左侧选中的连接和右击编辑的连接是同一个。第二修改后没有触发驱动的重新加载。建议把连接窗口彻底关掉甚至重启一下DBeaver再测试因为某些版本对动态属性的热加载支持得不够干净。第三属性键名大小写错误。JDBC驱动对参数名是大小写敏感的如果写成allowpublickeyretrieval或AllowPublicKeyRetrieval驱动无法识别等于没设。第四DBeaver缓存了旧的连接失败状态。在“连接”菜单里选择“断开连接”然后重新“新建连接”向导测试有时候比在原连接上反复点“测试连接”更有效。提示如果连接配置里的SSL选项被设置成了“需要加密”那光设allowPublicKeyRetrievaltrue可能还不够还要保证服务器端的SSL证书能被客户端信任。2.3 这种设置安全吗很多人一看到true就觉得是不是关闭了什么保护其实allowPublicKeyRetrievaltrue只是允许客户端在连接阶段从服务器获取RSA公钥密码本身依然使用这个公钥加密后再传输并不是明文裸奔。真正的风险在于“首次获取公钥时无法验证公钥身份”这在极端严格的网络安全要求下会被视为弱点。但如果你只是本地开发、内网测试几乎可以忽略这个风险。公共网络或生产环境则建议配合SSL或者手动导入服务器证书而不是依赖动态公钥检索。我的建议是本地开发库直接开allowPublicKeyRetrievaltrue高效省事生产环境单独走SSL或者专用隧道不要图省事。3. 方案二JDBC URL里显式追加参数3.1 一段可以直接复制的URL写法如果你不是在DBeaver里操作而是写Java代码或者使用其他支持JDBC的报表工具那解决办法就是在连接URL后面显式带上参数。典型的MySQL 8.0 JDBC连接串如下jdbc:mysql://127.0.0.1:3306/yourdb?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/Shanghai这里allowPublicKeyRetrievaltrue是主角useSSLfalse是因为本地链路本来就是内网明文没必要走SSL握手徒增延迟而serverTimezoneAsia/Shanghai是顺手处理掉时区报错这条参数本身和公钥检索无关但很多项目在MySQL 8.0下会同时踩两个坑索性一起写全。如果是Spring Boot项目写进application.yml大概是这样spring: datasource: url: jdbc:mysql://127.0.0.1:3306/yourdb?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver3.2 参数之间的连带关系这三个参数看似独立其实是一套组合。useSSLfalse告诉客户端不要加密传输allowPublicKeyRetrievaltrue允许客户端向服务器拿公钥。两条都设了客户端会拿公钥加密密码完成认证。如果只设useSSLtrue而没有配置证书客户端会要求服务器提供合法证书这一下子把问题从“公钥检索被禁止”升级成了“证书校验失败”反而更麻烦。所以在本地开发环境useSSLfalse和allowPublicKeyRetrievaltrue建议成对出现。某些非常古老的MySQL Connector/J 5.x版本根本不认识allowPublicKeyRetrieval这个参数就算拼接上去也没用甚至会被驱动忽略。遇到这种情况先升级驱动版本不要跟参数较劲。3.3 其他常见客户端工具是否适用这个思路不局限在DBeaver。Navicat、DataGrip、DbVisualizer等工具凡是基于JDBC连接MySQL的都会在连接配置界面里有类似的驱动属性项只是名称和位置不同。Navicat里是“高级”页签下的allowPublicKeyRetrievalDataGrip则和DBeaver类似在驱动属性里添加。如果你在公司运维统一管理的内网环境里不方便改客户端的场景也可以直接跳到下一节从服务端角度解决。4. 方案三调整MySQL用户认证插件4.1 从服务端查清楚当前认证方式有些场景下你根本没法改客户端配置比如数据库被多个部门共用每个人用的工具都不一样。这时候最稳妥的办法是从服务端把用户的认证插件改为兼容性更好的mysql_native_password。登录MySQL后先查看当前用户用的什么插件SELECT user, host, plugin FROM mysql.user WHERE user root;正常情况下MySQL 8.0新建的用户默认显示caching_sha2_password。如果你面对的正是这种情况那客户端报Public Key Retrieval is not allowed就有了根因。4.2 一条SQL切换到旧版认证插件确认插件之后用下面的语句把用户切换回mysql_native_passwordALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 你的密码; FLUSH PRIVILEGES;注意两点。第一rootlocalhost里的localhost要和实际连接来源匹配。如果你通过内网IP连接那么用户可能是root%或root内网IP必须以mysql.user表里实际记录为准。第二BY 你的密码必须写即使密码跟原来一样也要写完整否则部分版本会执行失败。执行完后DBeaver默认连接配置直接重连不需要再改任何驱动属性。因为mysql_native_password认证流程不涉及公钥加密自然绕开了Public Key Retrieval的限制。4.3 这种方案有什么代价我要提醒一句mysql_native_password虽然解决了兼容性问题但它是比caching_sha2_password更老的认证方案安全强度相对弱。如果数据库在公网上暴露不建议为了省事降级认证插件。另外MySQL官方对mysql_native_password的态度也越来越明确它默认情况下在新版本中仍旧可用但属于“过时的代名词”未来版本大概率会进一步收紧。因此我的建议是只有在你明确知道有一堆老旧客户端连接、没法一一改参数时才用这个方案应急。新项目最好从一开始就拥抱caching_sha2_password配合客户端参数解决。5. 驱动版本、SSL与内网环境的连带问题5.1 驱动版本过旧也会干扰判断我见过一种情况客户端参数全部设置正确但还是连不上最后发现是DBeaver自带的MySQL驱动版本太老。旧版Connector/J对caching_sha2_password的支持并不完善甚至会在更早的阶段报出Access denied或Unable to load authentication plugin。DBeaver的驱动管理入口在“数据库”菜单下的“驱动管理器”双击MySQL驱动可以看到当前版本号。如果版本号是5.x建议更新到8.x以上。通常DBeaver社区版会内置较新的驱动但如果你手动替换过驱动偶尔会混入旧版本。更新驱动后请重新创建一个连接测试不要在旧连接上硬改。因为旧连接可能已经缓存了驱动实例即使驱动配置变了运行中的连接池仍然会是旧驱动。5.2 SSL参数的几种配置结果把场景拉回到useSSL上这个参数有三个常见取值范围true、false和PREFERRED。很多朋友不理解为什么设了true反而连不上这里补两句。useSSLtrue时客户端要求服务器提供合法SSL证书并完成证书链校验。如果服务器没有配置SSL证书或者证书不被客户端信任就会在连接阶段直接失败报错内容通常是SSL connection error或Communications link failure而不是Public Key Retrieval。useSSLPREFERRED时客户端会先尝试SSL连接如果SSL不可用则自动降级到普通连接。这种模式看起来安全但在公钥检索问题上反而可能多一层干扰我不建议在排查阶段使用这种模棱两可的取值。本地开发的最佳实践是明确useSSLfalse配合allowPublicKeyRetrievaltrue简单直接不要给排查留模糊空间。5.3 内网环境为什么也会触发有个认知误区是“内网连接不经过公网密码不加密也无所谓。”但问题在于MySQL服务端并不这么认为它不会因为客户端IP在内网就跳过认证阶段的公钥加密流程。caching_sha2_password的协议设计决定了非SSL连接下就一定要走RSA公钥加密密码这条路跟你是不是内网没有任何关系。所以哪怕DBeaver和MySQL装在同一台机器上只要连接属性没放开公钥检索限制这个错误照样出现。搞明白这点你就不会再浪费时间折腾防火墙、账号权限、网络连通性这些无关痛痒的方向了。6. 排查复盘开发机连接MySQL 8.0的完整顺序6.1 常见问题速查表报错或表现可能原因处理方式Public Key Retrieval is not allowed驱动属性允许公钥检索为false设置allowPublicKeyRetrievaltrueAccess denied for user密码错误或账号权限不足核对密码及mysql.user表host匹配情况Unable to load authentication plugin驱动版本过旧更新到MySQL Connector/J 8.xSSL connection error服务端无有效证书或证书校验失败本地连接设置useSSLfalseCommunications link failure网络不通或端口被拦截检查3306端口、防火墙、bind-addressUnknown database数据库名拼写错误确认连接URL中的库名存在6.2 我的排障路径参考先说明一下我在实际处理这类问题时有个固定顺序不一定适用于所有人但至少能避免你走弯路。第一步永远是在DBeaver里看“驱动属性”页面直接锁定allowPublicKeyRetrieval和useSSL两个值。多数情况下问题出在这里。第二步确认MySQL版本如果是8.0且用户插件是caching_sha2_password回到驱动属性排查而非改服务端。第三步查看驱动版本号把驱动升级到合理的新版本。第四步才考虑登录MySQL查看用户插件、做服务端变更。还有一个很容易被忽略的小问题如果DBeaver里的连接配置着localhost但MySQL用户表里只存在root127.0.0.1或root%连接时会因为用户不匹配报错。把这个维度也纳入检查清单排查会快很多。6.3 一点个人体会这个报错在刚接触MySQL 8.0的人眼里像一道天堑但把原理吃透之后你会发现它其实是一道开放题客户端配置、服务端配置、URL参数三条路都能走通。我自己平时最常用的是DBeaver驱动属性加参数因为改动最小、可回滚、不影响其他用户。唯一会直接改服务端认证插件的场景是团队里有传统BI工具连库老旧的驱动没办法动态改参数只能从数据库侧迁就。如果你现在正好被这个错误卡住可以按第2节的步骤先操作一遍十有八九当场就能连上。实在不行再往下检查驱动版本和服务端插件问题边界很清楚不需要慌。最后再分享一个小经验改完连接配置之后不要只对着“测试连接”窗口看结果把当前连接关掉重开甚至重启一下DBeaver有时能规避很多莫名奇妙的缓存问题。等你把这条连接跑顺了再回头对比一下自己之前填的参数基本就能彻底理解这个错误的前因后果了。