SSH 密钥算法 Ed25519 与 RSA 的前世今生，以及今天该怎么用

很多人第一次接触 SSH，都是从一行命令开始的：

ssh-keygen -t rsa

这条命令并没有错，但它背后有一个经常被忽略的问题： 我们讨论的到底是“RSA 这种密钥类型”，还是 ssh-rsa 这种“签名算法”？

这两个概念在很多旧教程里被混用，导致不少人一边以为自己“还在用老旧不安全方案”，一边又不知道怎么迁移，甚至在新系统和老设备之间反复踩坑。

这篇文章就把这件事讲清楚：

1. RSA 和 Ed25519 在 SSH 世界里是怎么一路走来的。
2. 为什么今天大家都在推荐 Ed25519。
3. 如果你线上还有一堆老机器，应该怎么稳妥迁移。
4. 2026 年这个时间点，个人和团队应该采用什么默认策略。

一、先把概念对齐：SSH 里不止一种“算法”

很多文章把 SSH 算法一把梭，实际上 SSH 协议里至少有四类东西：

1. 密钥交换算法（KEX）：决定会话密钥怎么协商。
2. 主机密钥算法（Host Key）：客户端如何确认“这台服务器就是它自己”。
3. 用户认证签名算法（Public Key Auth）：你登录时，客户端拿私钥做签名，服务器验签。
4. 对称加密/MAC：会话建立后数据如何加密与完整性保护。

我们今天重点说的 RSA 和 Ed25519，主要落在第 2 和第 3 类。

这也是为什么你会看到这些名字同时出现：

• ssh-ed25519
• ssh-rsa
• rsa-sha2-256
• rsa-sha2-512

其中最容易误解的是：

• RSA 是非对称算法家族（密钥类型）。
• ssh-rsa 是“RSA + SHA-1”这一类签名标识。
• 现在被推荐的是“RSA 密钥 + SHA-2 签名”（rsa-sha2-256/512），而不是 ssh-rsa（SHA-1）。

只要这层理清，后面所有配置基本都能看懂。

二、RSA 的前世：为什么它曾经一统江湖

RSA 的历史很长，放在 SSH 里看，大致可以分几段：

1. 1977 年，RSA 公开发表，成为现代公钥密码学最重要的基石之一。
2. 90 年代到 2010 年前后，RSA 在各种协议里都几乎是“默认选项”。
3. 早期 SSH 生态（尤其老系统和老固件）大量使用 RSA，并长期沿用 ssh-rsa 标识。

它能长期占主流，原因很现实：

1. 实现成熟，库和硬件支持广。
2. 兼容性好，几乎所有系统都认识它。
3. 管理员熟悉，文档与教程极多。

但问题也一样现实：

1. 为了达到同等安全强度，RSA 密钥通常更大（常见 2048/3072/4096 bit）。
2. 在握手和签名场景下，速度和资源开销不占优势。
3. 早年大量部署绑定了 SHA-1 的 ssh-rsa，而 SHA-1 早已不再适合作为长期安全基线。

后面大家感受到的“RSA 不安全”争论，本质上大多数时候是在说： 老的 ssh-rsa（SHA-1）不应再作为默认；不是说 RSA 数学本身立刻不能用了。

三、Ed25519 的今生：它为什么成为默认推荐

Ed25519 来自 Edwards 曲线体系，在工程上非常“运维友好”：

1. 密钥短，公钥和私钥都更轻量。
2. 签名快、验签快，CPU 压力更小。
3. 参数固定，减少“曲线参数选错”的概率。
4. 在现代 OpenSSH 里支持成熟，默认体验好。

你可以把它理解成： 在“日常 SSH 登录和自动化运维”这个具体场景中，Ed25519 给了更好的性能/安全/可用性平衡点。

所以今天大多数新环境，默认优先级是：

1. 首选 Ed25519。
2. 兼容兜底才使用 RSA（并尽量使用 SHA-2 签名）。

四、一个关键分水岭：ssh-rsa 被默认淘汰之后

很多人是在某次系统升级后，突然遇到这类报错才开始研究算法问题：

• no matching host key type found
• no matching key exchange method found
• userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms

这背后的核心变化是：

1. 新版本 OpenSSH 不再默认接受基于 SHA-1 的 ssh-rsa 签名。
2. 但仍可使用 RSA 密钥，只要协商的是 rsa-sha2-256 或 rsa-sha2-512。

这就是“RSA 还能不能用”争论的标准答案：

• 能用，但别把 ssh-rsa 当默认。
• 新系统以 Ed25519 为主，RSA 作为兼容层。

五、2026 年推荐基线：个人与团队该怎么选

下面这套策略，适合绝大多数个人开发者、小团队和一般企业运维。

1) 用户登录密钥策略

1. 默认创建 ed25519 用户密钥。
2. 强制私钥口令（passphrase），并配合 ssh-agent。
3. 仅在必须兼容旧设备时，额外保留一把 RSA 3072/4096 密钥。

2) 服务器 Host Key 策略

1. 至少启用一把 Ed25519 主机密钥。
2. 可同时保留 RSA 主机密钥用于老客户端兼容。
3. 拒绝或最小化 ssh-rsa（SHA-1）签名路径。

3) 认证与访问控制策略

1. 关闭密码登录，使用公钥认证。
2. 禁止直接 root 密码登录。
3. authorized_keys 做细粒度限制（来源 IP、命令限制、禁止端口转发等）。

4) 合规例外（FIPS 等）

在某些强合规环境中，Ed25519 可能不是可用选项。遇到这类场景时：

1. 按组织合规基线执行（通常是特定曲线或 RSA 方案）。
2. 不要“个人偏好优先于审计要求”。
3. 在合规与兼容约束下，尽量使用 SHA-2 签名与最小权限策略。

六、实操一：客户端正确生成与使用密钥

1) 生成 Ed25519 密钥（推荐）

ssh-keygen -t ed25519 -a 64 -C "your_email@example.com"

说明：

1. -a 64 是 KDF 轮数，提升口令抗暴力破解能力。
2. 生成后建议确认私钥文件权限是 600。

2) 添加到 agent

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

3) 服务器安装公钥

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server

4) 客户端 ~/.ssh/config 示例

Host prod-main
  HostName 203.0.113.10
  User deploy
  Port 22
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes
  ServerAliveInterval 30
  ServerAliveCountMax 3

这套配置的核心目的只有一个： 让连接行为可预测，不要把本机一堆私钥乱试一遍。

七、实操二：服务端 sshd_config 的一份稳健模板

以下示例是通用安全基线，实际请按发行版路径与版本调整：

# /etc/ssh/sshd_config

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
AuthenticationMethods publickey
MaxAuthTries 3

# Host keys
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# Prefer modern public key signature algorithms
PubkeyAcceptedAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

修改后建议先做两步：

sshd -t
systemctl reload sshd

注意是 reload 优先，不要上来就 restart 把自己关在门外。

八、从老 RSA 环境迁移：一套低风险步骤

很多线上环境的问题不是“不会配”，而是“不能断”。 建议按下面步骤走，几乎可以把风险压到最低。

第 1 步：先盘点

1. 统计所有服务器、跳板机、CI 节点的 SSH 客户端版本。
2. 找出仍依赖 ssh-rsa 的系统（通常是老 NAS、老交换机、老发行版）。
3. 识别所有自动化任务（Ansible、CI/CD、备份脚本）的密钥类型。

第 2 步：先加不减

1. 给服务器先加 Ed25519 host key。
2. 给运维账号先加 Ed25519 用户公钥。
3. 保留原 RSA 兼容路径，观察一段时间。

第 3 步：分批切换默认

1. 客户端默认 IdentityFile 改为 Ed25519。
2. CI 任务密钥逐个替换，避免一次性全量切。
3. 日志观察认证失败原因，确认没有关键业务受影响。

第 4 步：收口

1. 对新环境禁止 ssh-rsa（SHA-1）签名。
2. 对历史孤岛设备做白名单例外，不把例外扩散到全局。
3. 把例外写进文档和配置管理，不要靠“记忆运维”。

九、常见误区与修正建议

误区 1：ssh-rsa 不能用 = RSA 完全不能用

修正：

• 不能默认用的是 ssh-rsa（SHA-1）签名。
• RSA 密钥配合 rsa-sha2-256/512 仍可作为兼容方案。

误区 2：只要是 Ed25519 就绝对安全

修正：

1. 私钥无口令、权限混乱、随意分发，一样会出事。
2. 安全性不只看算法，还看密钥生命周期管理。

误区 3：为了兼容，在全局开启老算法

修正：

1. 只对特定主机写例外配置。
2. 避免在全局 Host * 上放宽算法，防止把风险扩散到所有连接。

例如，仅对老设备临时例外：

Host legacy-switch
  HostName 198.51.100.20
  User admin
  PubkeyAcceptedAlgorithms +ssh-rsa
  HostKeyAlgorithms +ssh-rsa

并在设备升级后及时删除这段配置。

十、最后给一份可执行清单（直接照着做）

如果你现在要把自己的 SSH 体系拉回到正确状态，可以按这份 checklist：

1. 新建 Ed25519 密钥，并设置强口令。
2. 服务器安装 Ed25519 用户公钥。
3. sshd_config 关闭密码登录，启用公钥认证。
4. 客户端 ~/.ssh/config 指定 IdentityFile 和 IdentitiesOnly yes。
5. 为老设备仅做“主机级别”临时兼容，不做全局放宽。
6. 盘点并替换 CI/CD 中遗留的弱配置。
7. 每季度复查一次 SSH 算法与密钥策略。

做到这 7 条，基本就能同时满足：

1. 日常运维稳定。
2. 性能与体验更好。
3. 安全基线不落后。
4. 老系统迁移过程可控。

结语

RSA 在 SSH 里的历史地位，确实是“功勋级别”； Ed25519 则是当下更适合作为默认选项的现代方案。

真正正确的做法，不是情绪化地“只押一种算法”，而是：

1. 以 Ed25519 建立新基线。
2. 用 RSA(SHA-2) 做受控兼容。
3. 把例外收敛到最小范围，并持续清理。

当你把“算法选择”变成“可审计、可迁移、可回滚”的工程实践，SSH 才算真正稳下来。