公钥检索被禁止：深入解析与解决方案 – wiki词典

作者： /

公钥检索被禁止：深入解析与解决方案

在信息技术领域，公钥加密是保障通信安全和身份认证的基石。然而，在某些特定场景下，我们可能会遭遇“公钥检索被禁止”的错误或行为限制。这通常不是一个系统故障，而是一种出于安全考虑的预设机制，旨在防止潜在的中间人攻击（Man-in-the-Middle, MITM）和其他安全风险。本文将深入解析“公钥检索被禁止”的含义、其背后的安全逻辑，并针对最常见的两种场景——SSH/Git连接和Java应用连接MySQL数据库——提供详细的解决方案。

引言：为何公钥检索会被禁止？

公钥检索，顾名思义，是客户端从服务器端获取其公钥的过程。这个过程本身似乎无害，但如果这一检索过程不通过安全的通道进行，或者没有适当的验证机制，恶意攻击者就可能在此过程中插入伪造的公钥，从而欺骗客户端，截获或篡改通信内容。因此，系统或应用程序为了强制执行更严格的安全措施，往往会默认禁止不安全的公钥检索。理解这一点，对于我们在面对此类问题时，选择安全且有效的解决方案至关重要。

第一部分：SSH/Git 环境中的公钥检索禁止

在使用SSH协议进行远程连接，尤其是在通过Git与GitHub、GitLab等代码托管平台交互时，我们可能会遇到“Permission denied (publickey)”的错误。尽管错误信息没有直接提及“公钥检索被禁止”，但其深层原因往往与公钥认证失败或相关配置不当有关，导致系统无法成功检索或验证公钥，进而拒绝连接。

深入解析 SSH/Git 公钥认证失败的原因

  1. 公钥未正确配置： 最常见的原因是您的公钥（客户端本地生成，通常是 id_rsa.pub 文件内容）尚未被添加到目标服务器的 ~/.ssh/authorized_keys 文件中，或者未在Git服务提供商的账户设置中登记。
  2. 文件或目录权限不正确： SSH协议对密钥文件和相关目录的权限有严格要求。如果权限过于宽松（例如，任何人可读写），SSH服务器会认为存在安全风险，从而拒绝使用这些文件进行认证。
    • 客户端私钥文件（如 ~/.ssh/id_rsa）的权限不正确。
    • 服务器端 ~/.ssh 目录或 authorized_keys 文件的权限不正确。
  3. SSH服务配置问题： 目标服务器的SSH守护进程（sshd）可能未启用公钥认证，或 AuthorizedKeysFile 的路径设置有误。
  4. 客户端使用错误的密钥： 您的SSH客户端可能尝试使用错误的私钥进行认证，或者私钥未被SSH代理（ssh-agent）加载。
  5. 密钥格式或类型不受支持： 密钥文件可能已损坏，或者使用了服务器不支持的密钥类型。
  6. SELinux或防火墙限制： 服务器上的安全增强型Linux (SELinux) 或防火墙规则可能阻止了SSH连接或公钥认证。
  7. Git URL不正确： 在Git中，如果使用了不正确的SSH URL格式（例如，使用HTTPS协议的URL进行SSH认证），也会导致认证失败。

SSH/Git 环境的解决方案

  1. 确保公钥已上传和配置：
    • 对于远程服务器： 确保您的公钥内容（例如 cat ~/.ssh/id_rsa.pub 的输出）已添加到目标服务器用户家目录下的 ~/.ssh/authorized_keys 文件中，每行一个公钥。推荐使用 ssh-copy-id username@remote_host 工具，它可以自动完成公钥复制和权限设置。
    • 对于Git服务： 登录您的GitHub/GitLab账户，在“Settings”->“SSH and GPG keys”或类似界面中添加您的公钥。
  2. 检查并修正文件权限：
    • 客户端本地：
      • chmod 700 ~/.ssh
      • chmod 600 ~/.ssh/id_rsa (或您的私钥文件)
    • 服务器端：
      • chmod 700 ~/.ssh
      • chmod 600 ~/.ssh/authorized_keys
      • 确保 ~/.ssh 目录及其内容的所有者是当前用户：chown -R username:username ~/.ssh。
  3. 检查SSH服务配置（服务器端）：
    • 编辑SSH配置文件 /etc/ssh/sshd_config。
    • 确保 PubkeyAuthentication yes 已启用（前面没有 # 注释）。
    • 检查 AuthorizedKeysFile 的路径是否正确，通常为 %h/.ssh/authorized_keys。
    • 修改后，重启SSH服务：sudo systemctl restart sshd 或 sudo service sshd restart。
  4. 使用SSH调试模式： 使用 ssh -v your_user@remote_host 或 ssh -vvv your_user@remote_host 命令以详细模式连接，查看输出日志。这能提供关于认证失败原因的宝贵线索。
  5. 确保使用正确的密钥： 如果您有多个SSH密钥对，请确保SSH客户端尝试使用正确的私钥。可以使用 ssh-add ~/.ssh/your_private_key 命令将其添加到SSH代理。
  6. 检查SELinux和防火墙： 如果服务器启用了SELinux或防火墙，请检查相关日志（如 /var/log/audit/audit.log）并配置相应的规则，确保SSH服务和端口（默认为22）未被阻断。

第二部分：Java 应用连接 MySQL 时的公钥检索禁止

当Java应用程序（特别是使用JDBC驱动）连接MySQL 8.0及更高版本的数据库时，可能会遇到明确的错误信息：“Public Key Retrieval is not allowed”。这通常与MySQL 8.0引入的更安全的默认身份验证插件 caching_sha2_password 有关。

深入解析 Java 连接 MySQL 公钥检索禁止的原因

  1. caching_sha2_password 认证插件： MySQL 8.0将 caching_sha2_password 设置为默认认证插件。当客户端（如Java应用）在未启用SSL/TLS加密连接的情况下，尝试使用此插件进行认证时，客户端需要从服务器获取RSA公钥来加密密码进行交换。
  2. 安全限制： 出于安全考虑，MySQL Connector/J（以及许多其他JDBC驱动）默认禁止客户端自动检索服务器的公钥。这是为了防止潜在的中间人攻击：如果允许自动检索，恶意攻击者可以在客户端与数据库之间伪装成数据库，向客户端发送伪造的公钥，从而窃取用户的数据库凭据。
  3. SSL/TLS禁用或不可用： 如果在JDBC连接字符串中明确禁用了SSL/TLS（useSSL=false），或者SSL/TLS配置不正确/不可用，客户端就无法通过加密通道安全地获取公钥，从而触发此错误。

Java 连接 MySQL 的解决方案

  1. 推荐（最安全）：启用SSL/TLS加密连接。
    这是解决此问题的最佳实践。通过启用SSL/TLS，客户端和服务器之间的通信将通过加密通道进行，公钥的交换和验证也将在这一安全框架内完成，从而避免了不安全的公钥检索需求。配置方式通常是在连接字符串中设置 useSSL=true，并可能需要配置信任库等。

  2. 允许公钥检索（仅适用于开发/测试环境，生产环境需谨慎）：
    您可以通过在JDBC连接字符串中添加 allowPublicKeyRetrieval=true 参数来明确允许公钥检索。
    示例：
    java
    jdbc:mysql://localhost:3306/your_database?useSSL=false&allowPublicKeyRetrieval=true

    • 警告： 官方文档明确指出，在没有SSL/TLS加密的情况下启用 allowPublicKeyRetrieval=true 可能会允许恶意代理执行中间人攻击，获取明文密码。因此，除非您完全理解并接受其安全风险，否则切勿在生产环境中使用此方法。它主要用于开发和测试阶段的便利。
    • 对于DBeaver等客户端工具： 在连接设置的“驱动属性”（Driver properties）中，找到 allowPublicKeyRetrieval 选项并将其设置为 TRUE。如果不需要SSL，通常也需要将 useSSL 设置为 FALSE。

  3. 更改MySQL用户认证插件（降低安全性）：
    如果确实无法使用SSL/TLS或 allowPublicKeyRetrieval=true，并且可以接受降低安全性的做法，您可以将MySQL用户的认证插件从 caching_sha2_password 更改回 mysql_native_password。
    执行以下SQL命令：
    sql
    ALTER USER 'your_user'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password';
    FLUSH PRIVILEGES;
    注意： mysql_native_password 是MySQL早期版本使用的认证方式，安全性低于 caching_sha2_password。此方法不推荐，仅作为最后的选项。

  4. 手动指定服务器公钥文件：
    如果必须禁用SSL/TLS，并且不能或不愿启用自动公钥检索，您可以手动获取MySQL服务器的RSA公钥，将其保存到本地文件，然后在JDBC连接字符串中通过 serverRSAPublicKeyFile 参数指定该文件路径。这种方法相对复杂，但比 allowPublicKeyRetrieval=true 更安全。

安全影响与最佳实践

“公钥检索被禁止”这一默认设置，无论是SSH还是MySQL连接，其核心都是为了增强安全性，防止未经授权的访问和数据泄露。

  • 防止中间人攻击： 强制安全通道或明确配置，确保客户端获取的公钥是真实服务器的公钥，而不是攻击者伪造的。
  • 保护凭据安全： 避免在不安全的网络环境中直接暴露或交换加密凭据所需的信息。

最佳实践：

  1. 始终优先使用加密连接： 对于任何涉及敏感数据或身份认证的通信，如SSH和数据库连接，都应优先启用SSL/TLS或类似的加密协议。
  2. 严格管理密钥和权限： 确保私钥文件受到严密保护，其文件权限设置遵循最小权限原则。定期审查和更新密钥。
  3. 避免在生产环境中使用不安全的选项： 对于像 allowPublicKeyRetrieval=true 这样的选项，只应在明确知道风险且仅限于开发/测试环境中使用。
  4. 保持软件更新： 及时更新SSH客户端、SSH服务器以及数据库驱动（如JDBC Connector/J），以获取最新的安全特性和漏洞修复。

总结

“公钥检索被禁止”是现代安全实践中的一个重要组成部分。它提醒我们，在进行远程通信和身份认证时，必须时刻关注安全。通过深入理解其背后的安全逻辑，并针对具体场景采取正确的解决方案，我们不仅能够解决连接问题，更能显著提升系统的整体安全性，有效抵御潜在的网络威胁。在追求便利的同时，永远不应忽视安全的重要性。

滚动至顶部