5-12 实现安全的远程通信 · 波仔的网络与信息安全课

📄 一句话概括

远程通信的安全要解决两件完全不同的事：把这条连接上的数据加密（SSH 的传输层、VPN 的隧道）和证明"对面那台机器/那个人是它自称的身份"（SSH 的钥匙、客户数字证书）——而 2026 年的关键变化是：SSH 的钥匙交换早就默认带后量子算法了，你什么都不用做；真正在换代的是 VPN 的形态（从"员工回家办公的通道"变成"机器与机器之间的通道"）。

📝 本节和前面几节的关系

5-6 讲了签名怎么证明"是谁"，5-9 给了密钥长度与安全等级的换算表，5-11 刚拆过一层邮件。

这一节继续往下拆：把"远程通信"这一个大词，拆成 SSH、客户数字证书、VPN、IPsec 四件具体的事。 这四件事有一个共同结构：加密负责"路上别被看见"，认证负责"对面是不是它"。

一、SSH：先选对钥匙，再分清两层

SSH 是管理员每天都在用的东西（远程登录服务器、传文件、跑 Git），但它内部其实有两套独立运行的密码学，混在一起谈就很容易糊涂。

先说钥匙选型。2026 年的答案很明确：

类型	密钥长度	公钥大小	2026 建议
Ed25519	256 位	约 68 字节	默认首选（约等于 RSA-3072 的安全）
RSA	3072/4096 位	约 540/740 字节	只用于必须兼容的老设备
ECDSA	256 位	约 90 字节	不建议新用（随机数重用会泄露私钥）
DSA	1024 位	已被禁用	删掉

Ed25519 的优势不只是"小"：同一个安全等级下，它的公钥只有 RSA-4096 的十分之一大小，签名和验证也快得多。而更值得知道的是它为什么比 ECDSA 更值得选——ECDSA 的一个致命弱点是签名的随机数（nonce）如果重复使用，私钥会直接被人算出来。这不是理论问题：2010 年索尼 PS3 的固件签名就是因为这个原因被攻破，签一个固件的私钥暴露之后，整个平台的签名体系等于作废。Ed25519 的签名是确定性的，从根本上没有这个隐患。

再说那两层结构，这是本节最实用的一张表：

层	解决什么	2026 状况
传输层（会话加密）	这条连接上的数据不被偷看	默认已是混合后量子密钥交换
认证层（你的钥匙）	证明你是你	仍以 Ed25519 为主，后量子在实验阶段

为什么要把这两层分开看？因为它们解决的是两个毫无关系的问题，而且换代节奏完全不同。

传输层关心的是"这条连接上的数据别被人偷看"——它由两边协商出来的临时密钥保护，跟你的钥匙无关。而这一层在 2026 年已经：OpenSSH 早就在默认的密钥交换算法里放进了后量子混合方案（sntrup761x25519-sha512、mlkem768x25519-sha256），双方自动协商，管理员不用做任何配置。
认证层关心的是"你凭什么证明你是你"——它靠的是你手上那把私钥。这一层的换代还在路上：OpenSSH 10.4 加入了实验性的混合签名算法（mldsa44-ed25519），但默认没有启用。

一句话结论：SSH 的【钥匙交换】早就默认带后量子算法了，所以你什么都不用做；但【签名算法】的换代还在路上。

这个"两半新、一半旧"的状态，正好解释了 5-9 那条迁移时间表为什么按系统类型分批：同一套协议里，不同部分的替换难度和风险根本不在一个量级。

二、客户数字证书：把"贴公钥"换成"由 CA 签发"

SSH 的认证层默认靠"贴公钥"：你把公钥写到服务器的 authorized_keys 文件里，服务器就把你认成"这把钥匙的主人"。 这在几台机器时完全没问题，但机器一多就崩了。

做法	扩展性	能不能设有效期
把公钥写进对方 authorized_keys	每加一台机器就要改一遍	不能
由 CA 签发客户证书	所有机器只信任同一个 CA	能（可短到几天）

把这件事算清楚：n 台客户端的每台都要访问 m 台服务器，前一种做法的维护量是 n×m。10 台客户端对 10 台服务器就是 100 次操作；机器从 10 台长到 1000 台时，前者是 n×m 的维护量，后者几乎不变——因为所有机器只需要信任同一个 CA，新增一台机器只是"发一张证书"，不需要去改任何服务器。

这就是"客户数字证书"，也就是把 5-4 那套 CA/PKI 体系原封不动搬到 SSH 上。它带来两个额外好处：一是可以设有效期（短到几天，和 5-10 讲过的"短命证书"是同一个思路）；二是可以精细授权——证书里能写明"这把钥匙可以登录哪些用户名、可以从哪些来源地址登录、有几天有效期"。

代价是你要维护一个 CA（哪怕是一个自签的 CA），而且它成了新的单点：CA 私钥泄露，等于所有客户端的钥匙都要重发。

三、VPN 与 IPsec：三种主流做法

VPN 这个词很容易被当成一种技术，其实它是一族做法的统称。它们都在解决同一个问题：让两台不在同一网络里的机器，像在同一网络里一样通信。 区别在于"工作在哪一层"。

方案	工作在哪一层	优势	代价
IPsec	网络层（IP 包里）	企业设备原生支持、互通性好	配置复杂、排错困难
WireGuard	网络层（内核态）	配置极简、代码量小、速度快	功能克制，需较新内核
TLS VPN	应用/传输层	走 443 端口，穿透性好	相对更慢、代码量更大

三者的差别可以用一句话概括：

IPsec 是"老资格"——它在 IP 层加密，所有企业级网络设备都原生支持它（路由器、防火墙、专线设备），所以跨厂商互通是它的强项。它的代价也是出了名的：配置项极多、两边参数必须完全对齐，出问题时很难判断是哪一项不匹配。
WireGuard 是"反着做"——它把代码量压到极小（相比之下 IPsec 的实现动辄几十万行），配置只有几行，性能却更好。代码少这件事本身就是安全优势：能被审出来的漏洞数量、以及出错的表面积，都跟着变小。它的代价是"功能克制"——它只做"建立加密隧道"这一件事，不做复杂的用户认证与策略下发，也要求较新的操作系统内核。
TLS VPN 是"借道"——它把隧道建在 443 端口上，看起来就是普通的 HTTPS 流量。因此在"对方防火墙只放行 443"的环境里，它是唯一能通的一种。代价是它在用户态运行、包了一层又一层，性能相对最差。

四、动手 Demo：钥匙选型、两层结构与三条 VPN 路线

下面这段输出把上面三节做成了一张可对照的表，最后一部分是 2026 年的实际数据——它说明 VPN 的用途正在发生一次不小的转移。

一、SSH 该用哪种钥匙（2026 年的答案很明确）
  类型        密钥长度      公钥大小          2026 建议
  Ed25519     256 位        约 68 字节        默认首选（约等于 RSA-3072 的安全）
  RSA         3072/4096 位  约 540/740 字节   只用于必须兼容的老设备
  ECDSA       256 位        约 90 字节        不建议新用（随机数重用会泄露私钥）
  DSA         1024 位       已被禁用          删掉
  → 同一个公钥，Ed25519 只有 RSA-4096 的十分之一大小，快得多。

二、SSH 里其实有【两层】密码学，别混在一起
  层                  解决什么                      2026 状况
  传输层（会话加密）  这条连接上的数据不被偷看      默认已是混合后量子密钥交换
  认证层（你的钥匙）  证明你是你                    仍以 Ed25519 为主，后量子在实验阶段
  → 值得注意：SSH 的【钥匙交换】早就默认带后量子算法了，
     所以你什么都不用做；但【签名算法】的换代还在路上。

三、客户数字证书：把【贴公钥】换成【由 CA 签发】
  做法                              扩展性                    能不能设有效期
  把公钥写进对方 authorized_keys    每加一台机器就要改一遍    不能
  由 CA 签发客户证书                所有机器只信任同一个 CA   能（可短到几天）
  → 机器从 10 台长到 1000 台时，前者是 n×m 的维护量，后者几乎不变。

四、VPN 与 IPsec：三种主流做法
  方案            工作在哪一层          优势                          代价
  IPsec           网络层（IP 包里）     企业设备原生支持、互通性好    配置复杂、排错困难
  WireGuard       网络层（内核态）      配置极简、代码量小、速度快    功能克制，需较新内核
  TLS VPN         应用/传输层           走 443 端口，穿透性好         相对更慢、代码量更大

五、2026 的实际数据
  指标                                      数值
  新部署中使用 WireGuard 的比例             61%（2023 年为 22%）
  全球 VPN 服务市场规模（2026Q1）           约 287 亿美元（2024 同期 214 亿，+34.1%）
  远程办公类 VPN 流量占比                   47%（2023 年为 65%）
  跨境数据交换 / 云接入 / 物联网等场景占比  38%（持续上升）
  → 趋势是：VPN 从【员工回家办公的通道】变成【机器与机器之间的通道】，
     同时零信任架构正在与 VPN 融合，取代【一次拨入就进内网】的旧模型。

最后一段是本节最值得记住的趋势：VPN 的用途正在从"人"转向"机器"。最能说明问题的一组数字是远程办公类流量的占比从 65% 降到 47%——总量在涨（市场规模一年涨 34.1%），但"人回家办公"这一块反而在缩，涨上来的是跨境数据交换、云接入、物联网设备之间的连接。换句话说，VPN 正在从"给员工开一扇门"变成"给机器之间拉一根专线"。

这背后是零信任（ZTNA）的思路在取代旧模型：旧模型是"拨入一次，就进了内网，之后随便走"；新模型是"每一次访问都要单独判断这个身份有没有权限"——而这件事正好用得上 5-6 学的签名和 5-12 学的客户证书。

五、⚠️ 2026 现状

1. WireGuard 已经从"新东西"变成"默认选择"。 2023 年它在新部署中只占 22%，到 2026 年已经到 61%——三年翻了近三倍。原因不是它"更安全"，而是它"更简单"：配置几行、代码量极小、进内核后速度快。对整个行业来说，这个迁移本身就是一条经验：在密码学工程里，"更少的代码"和"更少的配置"往往比"更多的功能"更能提升实际安全性。

2. SSH 的后量子迁移是"一半已经完成"的状态，而且不需要你做任何事。 OpenSSH 早就在默认密钥交换算法里放进了混合后量子方案（sntrup761x25519-sha512 与 mlkem768x25519-sha256），双方自动协商——这正是 5-7 里讲的"混合"思路：用一个经典算法和一个后量子算法各算一次，两个都对才接受，所以即使新算法后来被发现有问题也不至于出事。而签名那一半还在实验阶段：OpenSSH 10.4 加入了实验性的 mldsa44-ed25519 混合签名，默认未启用。所以今天的实际状态是：连接本身已经抗量子，但"你的钥匙"还是老的。

3. 硬件钥匙把"私钥不出设备"变成了现实。 ed25519-sk、ecdsa-sk 这类"安全钥匙"类型的密钥，私钥生成和使用都在硬件里，机器上只留下一份引用——也就是说，即使某台机器被入侵，攻击者也拿不到能复用的私钥，他必须先物理拿到那把钥匙。FIDO2/WebAuthn 用的就是同一套硬件（这也是 5-14 里讲到"只有 FIDO2 能挡住实时转发攻击"的同一个原因）。

4. 远程连接的重心转移，带来的安全含义是"攻击面从人变成了身份"。 当 38% 的 VPN 流量是机器与机器之间的（跨境数据交换、云接入、物联网），"人"就不再是唯一的访问主体——这意味着认证方式必须能自动完成（证书、密钥，而不是密码和短信码），授权必须能被审计（哪台机器在什么时间访问了什么）。旧模型"拨入一次就进内网"在这里彻底失效，因为一台被入侵的物联网设备拨入之后，会在内网里畅通无阻——这正是 2-8 讲过的"边界在哪里"的问题在 2026 年的新答案。

30 秒实验

看你自己用的是什么 SSH 钥匙。 在终端（或 Windows 的 PowerShell）里敲：

ls ~/.ssh

如果看到 id_ed25519，说明你用的是 2026 年推荐的类型；如果看到的是 id_rsa，敲下面这条看它的位数：

ssh-keygen -l -f ~/.ssh/id_rsa.pub

输出的第一个数字就是位数：如果是 2048，按上面的表它只该用于兼容老设备；3072 或 4096 才算合格。如果这个文件不存在，说明你还没生成过钥匙——这也正常，说明你还没配过免密登录。

看你的 SSH 客户端支持不支持后量子算法。 敲：

ssh -Q kex

它会列出你这台机器支持的密钥交换算法。 在列表里找有没有带 mlkem 或 sntrup 字样的条目——如果有，说明你已经在用"混合后量子"了，而且这是默认行为，你不需要配置任何东西。这就是本节最反直觉的一点：这一层的升级是静悄悄完成的。

常见误区

错误：SSH 安全不安全，就看密钥长不长。——纠正：SSH 里有两套独立的密码学，只看钥匙等于只看了认证层。传输层（会话加密）用的是两边协商出来的临时密钥，跟你的钥匙无关，而它在 2026 年已经默认启用混合后量子密钥交换——也就是说，你的密钥交换已经抗量子了，但你手里那把钥匙还是老的。要评估一台 SSH 服务器是否安全，必须分别看"协商了什么密钥交换算法"和"接受哪些类型的客户端密钥"。
错误：ECDSA 和 Ed25519 都是椭圆曲线，随便用哪个都行。——纠正：两者虽然同属椭圆曲线家族，但 ECDSA 有一个致命弱点——签名的随机数（nonce）如果重复使用，私钥会被直接算出来。这不是理论风险：2010 年索尼 PS3 的固件签名就因为 nonce 重用被攻破，签一个固件的私钥暴露后整个平台的签名体系都作废了。Ed25519 的签名是确定性的，从根本上没有这个隐患，所以在 2026 年，ECDSA 被明确列为"不建议新用"。 这也说明一件事：评估一个算法不能只看"数学强度"，还要看"它在工程上有多容易被用错"。
错误：客户数字证书只是"省事的公钥管理"，安全性和贴公钥差不多。——纠正：它多了两个贴公钥给不了的能力。一是有效期：客户证书可以短到几天，过期即失效，不必像 authorized_keys 那样"一旦加上就一直有效，除非有人记得删"（对照 5-10 里"短有效期替换吊销"的同一个思路）。二是精细授权：证书里能写明限定的用户名、限定的来源地址、限定的有效期，而 authorized_keys 里的一行只能用命令选项做很粗糙的限制。
错误：VPN 就是给远程办公的人用的。——纠正：这个印象在 2026 年已经过时了。远程办公类 VPN 流量占比从 65% 降到了 47%，而跨境数据交换、云接入、物联网这些"机器与机器"的场景升到了 38% 并且还在涨——全球 VPN 市场同期还在以 34.1% 的速度增长。也就是说，VPN 正在从"给员工开一扇门"变成"给机器之间拉一根专线"，这个转移直接改变了安全设计：认证必须能自动完成（证书、密钥），授权必须可审计——因为一台被入侵的物联网设备可不会"下班"。

自测三问（点开对答案）

1. SSH 里的"两层密码学"分别是什么？为什么要把它们分开看？ —— **两层是：传输层（会话加密）与认证层（你的钥匙）**。**传输层解决"这条连接上的数据不被偷看"**，**它用的是两边协商出来的临时密钥，跟你的手上那把钥匙无关**；**认证层解决"证明你是你"**，**它靠的是你手上那把私钥**。**要分开看的原因是：两者换代节奏完全不同**——**传输层在 2026 年已经默认启用混合后量子密钥交换（`mlkem768x25519-sha256` 这类），双方自动协商，管理员不用做任何配置**；**而认证层的签名算法换代还在实验阶段（OpenSSH 10.4 的 `mldsa44-ed25519` 默认未启用）**。**所以今天的实际状态是"连接本身已经抗量子，你的钥匙还是老的"。** 2. 为什么 2026 年不建议新用 ECDSA？ —— **因为它的签名依赖一个随机数（nonce），而这个随机数一旦重复使用，私钥会被直接算出来**——**这是算法结构上的问题，不是实现 bug**。**2010 年索尼 PS3 的固件签名就是这样被攻破的**：**攻击者发现两次签名用了同一个随机数，由此推出私钥，进而能给任意固件签名**。**相比之下 Ed25519 的签名是确定性的（同样的输入永远得到同样的签名），根本不存在"随机数重复"这个失败模式**；**而且它的公钥只有约 68 字节，是 RSA-4096 的十分之一，签名验证也更快**。**所以选型原则是：能用 Ed25519 就用 Ed25519，RSA 只在必须兼容老设备时保留，ECDSA 不建议新用，DSA 直接删。** 3. WireGuard 为什么能在三年里从 22% 涨到 61%？ —— **因为它把"简单"当成了核心设计目标，而简单在这里直接等于安全与性能**。**具体好处有三条**：**配置极简**（几行就能建隧道，而 IPsec 的两边参数必须完全对齐，出问题很难定位）；**代码量极小**（相比之下 IPsec 实现动辄几十万行，代码少意味着能被审出来的漏洞少、出错表面积小）；**在内核态实现，速度快**。**它的代价是功能克制**——**只做"建立加密隧道"这一件事，不做复杂的用户认证与策略下发，并要求较新的内核**。**这也正好说明本节的一条经验：在密码学工程里，"更少的代码、更少的配置"往往比"更多的功能"更能提升实际安全性。**

☐ 下一节（5-13 为软件添加数字签名）