OpenSSH 8.9 下 RSA 密钥还能不能用？实测三种协商策略

2026-09-12 · 约 3 分钟 · 1010 字

新版 OpenSSH 禁用的是 SHA-1 签名，不是 RSA 本身。用同一把 RSA 密钥强制三种不同算法策略，得到明确结论：默认可用、强制 rsa-sha2-256 可用、强制 ssh-rsa 被拒。

结论先行

RSA 密钥仍然可用。 被禁用（自 OpenSSH 8.8 起默认）的是 ssh-rsa 这个签名算法——它用 SHA-1。RSA 密钥可以改用 RFC 8332 定义的 rsa-sha2-256 / rsa-sha2-512 签名，而现代客户端都会。

判别方法很直接：

sshd -T | grep -i pubkeyacceptedalgorithms

输出里出现 rsa-sha2-256 和 rsa-sha2-512，说明 RSA 密钥能工作；ssh-rsa 是否也在列表里，与 RSA 密钥能否使用是两件事。

用同一把密钥跑三组对照

只看配置项是推断。做端到端实验才是证据：生成一把临时 RSA 密钥、加入授权列表、用三种客户端策略分别连接。

ssh-keygen -t rsa -b 2048 -N '' -f /tmp/rsa-probe -q

# 组 1：默认（允许协商降级）
ssh -i /tmp/rsa-probe -o BatchMode=yes -p <端口> user@host 'echo AUTH_OK'

# 组 2：强制 rsa-sha2-256
ssh -i /tmp/rsa-probe -o PubkeyAcceptedAlgorithms=rsa-sha2-256 \
    -o BatchMode=yes -p <端口> user@host 'echo AUTH_OK'

# 组 3：强制旧式 SHA-1 签名
ssh -i /tmp/rsa-probe -o PubkeyAcceptedAlgorithms=ssh-rsa \
    -o BatchMode=yes -p <端口> user@host 'echo AUTH_OK'

实测结果：

三组用同一把密钥、同一台服务端，唯一变量是签名算法。所以结论无歧义：

• 密钥本身没问题
• 服务端接受现代 RSA 签名
• 只有 SHA-1 那条路被关掉了

注意第三组失败在认证阶段（Permission denied）而不是密钥交换阶段——这和上一类问题（主机密钥协商失败）的症状不同，日志位置也不同，可以作为区分依据。

对客户端的要求

只需支持 RFC 8332，也就是 rsa-sha2-256 / rsa-sha2-512。实际覆盖范围很宽：

• OpenSSH 7.2（2016 年）及以后
• PuTTY 0.75（2021 年）及以后
• 各主流图形客户端近几年的版本

也就是说，2021 年之后的客户端基本都没问题，遇到的多是长期未更新的环境。

不要用降级解决问题

客户端连不上时，一个看起来很直接的"修复"是在服务端加：

# 不推荐
PubkeyAcceptedAlgorithms +ssh-rsa

这等于把这台机器的 SSH 认证降级回 SHA-1。SHA-1 的碰撞攻击早已实用化，用它给认证签名是在主动放弃防护。同样的道理适用于为兼容老客户端而放开 hmac-sha1 系 MAC、diffie-hellman-group1-sha1 之类的交换算法——兼容性问题的正确解法在客户端侧（更新客户端，或换一把 ed25519 密钥），不在服务端降级。

一个例外值得提：如果确实有无法更新的设备（老旧网络设备、嵌入式系统），更好的折中是只在特定密钥上放宽，而不是全局放宽：

# 只对指定客户端放宽，而不是放开全部
Match Address 203.0.113.0/24
    PubkeyAcceptedAlgorithms +ssh-rsa

顺带：2048 位 RSA 的强度

RSA 2048 的安全强度大约相当于 112 位对称强度，与 ed25519（约 128 位）相比是偏低的。这不是紧急问题，但有两个实际考虑：

• 同等强度对标 ed25519 需要 RSA 3072
• RSA 的签名过程不做 ed25519 那种抗侧信道设计，且密钥和签名都大得多

如果生成时间在近两年、且没有必须用 RSA 的理由，ssh-keygen -t ed25519 是更好的默认值。反过来，如果密钥要在多种设备间使用，RSA 的兼容面确实更宽——这是一个真实存在的取舍，值得按实际设备情况决定，而不是无脑选新。

小结

• ssh
• openssh
• rsa
• cryptography

← 全部文章