Gerrit SSH key配置踩坑实录：明明加了公钥还是Permission denied？试试这招

Gerrit SSH密钥配置深度排障指南：从Permission denied到安全连接

当你满心欢喜地配置完Gerrit SSH密钥，准备开始一天的代码提交工作时，终端却无情地抛出一行红色错误："Permission denied (publickey). fatal: Could not read from remote repository"。这种挫败感，相信每个开发者都深有体会。本文将带你深入剖析这一常见问题的根源，并提供一套完整的解决方案，特别是针对现代OpenSSH环境的安全最佳实践。

1. 问题现象与初步诊断

Permission denied错误表面上看是认证失败，但背后的原因可能错综复杂。我们先来还原一个典型的错误场景：

$ git clone ssh://username@gerrit.example.com:29418/project.git Cloning into 'project'... username@gerrit.example.com: Permission denied (publickey). fatal: Could not read from remote repository.

关键诊断步骤是使用-v(verbose)参数运行SSH命令，获取详细调试信息：

$ ssh -v username@gerrit.example.com -p 29418 ... debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:xxx debug1: Authentications that can continue: publickey debug1: Trying private key: /home/user/.ssh/id_dsa debug1: Trying private key: /home/user/.ssh/id_ecdsa debug1: Trying private key: /home/user/.ssh/id_ed25519 debug1: No more authentication methods to try. username@gerrit.example.com: Permission denied (publickey).

从输出中可以观察到几个关键点：

• SSH客户端尝试了多种密钥类型(RSA, DSA, ECDSA, Ed25519)
• 服务器只接受publickey认证方式
• 认证过程最终失败

2. 根本原因深度解析

2.1 OpenSSH 8.8+的安全策略变更

2021年发布的OpenSSH 8.8引入了一项重大变更：默认禁用RSA/SHA-1算法。这是因为它存在以下安全隐患：

这项变更直接影响了许多仍在使用传统RSA密钥的Gerrit服务器和客户端。即使你正确添加了公钥，如果服务器运行的是OpenSSH 8.8+，它可能会拒绝RSA密钥。

2.2 密钥类型不匹配

Gerrit服务器可能配置为只接受特定类型的密钥。常见的情况包括：

• 服务器sshd_config中设置了PubkeyAcceptedKeyTypes，限制了可接受的密钥类型
• 客户端生成的密钥类型不在服务器支持范围内
• 密钥文件权限设置不正确(如.ssh目录权限应为700，私钥文件权限应为600)

2.3 多密钥管理混乱

当系统存在多个SSH密钥时，SSH客户端可能没有使用你期望的密钥。常见症状包括：

• 客户端尝试了错误的密钥文件
• ssh-agent缓存了旧的密钥
• 配置文件(~/.ssh/config)中指定了不匹配的密钥

3. 现代SSH密钥最佳实践

3.1 生成Ed25519密钥

Ed25519是目前推荐的SSH密钥算法，它相比RSA具有以下优势：

• 更短的密钥长度(256位 vs RSA-2048的2048位)
• 更快的签名验证速度
• 更强的抗侧信道攻击能力
• 不被OpenSSH 8.8+限制

生成命令：

ssh-keygen -t ed25519 -C "your.email@example.com" -f ~/.ssh/id_gerrit

生成过程中会提示：

1. 输入保存密钥的文件路径(建议使用有意义的名称如id_gerrit)
2. 设置密钥密码(可选但推荐)
3. 确认密码

3.2 多密钥环境配置

对于需要管理多个Gerrit账户或项目的开发者，合理的.ssh/config配置至关重要：

Host gerrit.company1.com HostName gerrit.company1.com User your_username IdentityFile ~/.ssh/id_company1 Port 29418 Host gerrit.company2.com HostName gerrit.company2.com User different_username IdentityFile ~/.ssh/id_company2 Port 29418

这种配置方式可以：

• 为不同服务器指定不同的密钥
• 简化连接命令(只需ssh gerrit.company1.com)
• 避免密钥选择错误

3.3 密钥部署与测试

将公钥添加到Gerrit后，验证步骤至关重要：

1. 首先确认公钥已正确添加：

cat ~/.ssh/id_gerrit.pub | xclip -selection clipboard # 或者 cat ~/.ssh/id_gerrit.pub

2. 然后使用以下命令测试连接：

ssh -T -p 29418 username@gerrit.example.com

成功的响应通常类似于：

**** Welcome to Gerrit Code Review ****

如果仍然失败，可以尝试以下诊断命令：

# 查看SSH支持的认证方法 ssh -Q PubkeyAcceptedAlgorithms # 检查服务器支持的认证方法 ssh -vvv username@gerrit.example.com -p 29418

4. 高级排障技巧

4.1 服务器端配置检查

如果你是Gerrit管理员或可以访问服务器，检查以下配置：

# 查看服务器OpenSSH版本 ssh -V # 检查sshd配置 grep -i "PubkeyAcceptedAlgorithms" /etc/ssh/sshd_config grep -i "HostKeyAlgorithms" /etc/ssh/sshd_config

推荐的服务器配置：

PubkeyAcceptedAlgorithms ssh-ed25519,ecdsa-sha2-nistp384,rsa-sha2-512 HostKeyAlgorithms ssh-ed25519,ecdsa-sha2-nistp384,rsa-sha2-512

4.2 客户端兼容性处理

对于必须使用RSA密钥的旧系统，可以通过以下方式临时解决：

# 在~/.ssh/config中添加： Host legacy-gerrit.example.com PubkeyAcceptedAlgorithms +ssh-rsa HostkeyAlgorithms +ssh-rsa

注意：这降低了安全性，只应作为临时解决方案

4.3 密钥转换与升级

如果已有RSA密钥需要升级到Ed25519：

1. 备份旧密钥：

cp ~/.ssh/id_rsa ~/.ssh/id_rsa.bak cp ~/.ssh/id_rsa.pub ~/.ssh/id_rsa.pub.bak

2. 生成新Ed25519密钥(如前所述)
3. 将新公钥添加到Gerrit
4. 测试新密钥工作后，可以安全删除旧RSA密钥

5. 自动化部署与CI/CD集成

在自动化环境中，SSH密钥管理需要特别注意：

安全实践：

• 使用专用部署密钥而非个人密钥
• 限制密钥的访问权限
• 定期轮换密钥

典型CI配置示例：

# 在CI环境中设置SSH mkdir -p ~/.ssh chmod 700 ~/.ssh echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_gerrit chmod 600 ~/.ssh/id_gerrit cat <<EOF > ~/.ssh/config Host gerrit-ci.example.com HostName gerrit-ci.example.com User ci-user IdentityFile ~/.ssh/id_gerrit StrictHostKeyChecking no EOF

密钥轮换检查清单：

1. 生成新密钥对
2. 将新公钥添加到Gerrit
3. 更新所有自动化系统中的私钥
4. 验证新密钥工作正常
5. 从Gerrit删除旧公钥
6. 安全销毁旧私钥

经过多年与各种SSH配置问题打交道，我发现大多数Permission denied问题都源于密钥类型不匹配或配置细节疏忽。特别是在企业环境中，不同系统可能运行不同版本的OpenSSH，保持密钥策略的一致性至关重要。最近一次为金融客户部署Gerrit集群时，我们全面迁移到了Ed25519密钥，并建立了自动化的密钥轮换流程，彻底告别了SSH认证问题。