密钥同步概述
聊密钥同步之前，我先说说自己的经历。几年前我维护过一个跨机房的数据同步系统，每天凌晨都会出现一批连接失败。查了半天，发现是密钥对没对齐——A机房换了密钥，B机房还是老配置。你说这事儿大吗？说白了就是配个文件的事儿。但就是这种细节，能让整个系统跪一上午。
密钥同步，本质上就是让通信双方持有相同的密钥材料。你想想看，加密算法再牛，如果两边密钥对不上，那也白搭。我个人习惯把密钥同步看作两道工序：一是密钥本身的传递，二是密钥状态的确认。很多故障出就出在第二道上——密钥确实传过去了，但忘了通知对端“我更新了”。
常见的密钥同步协议，主要有三种：SSH、Kerberos、TLS。每种协议的同步机制不一样，适用的场景也不同。咱们一个一个来拆。
SSH密钥同步原理
SSH的密钥同步，我一般把它分成两个层面来看：一是主机密钥，二是用户密钥。
主机密钥，就是服务器用来证明“我是我”的那把钥匙。客户端第一次连SSH的时候，会收到服务端发来的主机公钥，然后问你“要不要信任它？”。你把公钥指纹确认后存到~/.ssh/known_hosts里，这就完成了第一次同步。以后再连，客户端会用存着的公钥去校验服务端是不是原样。
用户密钥呢，更常见。你生成一对密钥，把公钥扔到服务器上，私钥自己留着。每次登录的时候，服务端发一个随机数，你用私钥签名后发回去验证——这就是公钥认证的核心流程。
SSH协议里有个很关键的点——密钥交换阶段。Client和Server会协商加密算法、交换临时密钥参数，然后生成一个共享的会话密钥。这个会话密钥只对当前连接有效，用完就丢。我在项目中遇到过一个问题：某次升级OpenSSH后，老客户端连不上，原因是密钥交换算法不匹配。查日志发现kex_exchange_identification阶段直接断了。
Host key verification failed、Permission denied (publickey)。前者是主机密钥不匹配，后者是用户密钥认证失败。
Kerberos密钥同步原理
Kerberos这套机制，说白了就是引入了一个“中间人”——KDC（密钥分发中心）。所有客户端和服务器都信任KDC，KDC帮它们协商密钥。
你登录的时候，先向KDC申请一个TGT（票据授权票据）。这个过程用你的密码派生的密钥来加密。KDC验证通过后，返回加密的TGT。然后你想访问某个服务，拿着TGT去申请服务票据——这个过程也是加密的。最后你拿着服务票据去访问服务，服务用自己和服务票据的密钥来解密。
你发现没有？整个过程中，密钥的同步是隐式的。用户和KDC共享一个密钥（来自于密码），服务和KDC也共享一个密钥。这些密钥在KDC数据库里维护，用户每次认证时不需要手动复制公钥什么的。
我曾经踩过Kerberos的一个坑：域控服务器的时间不同步，导致票据验证失败。Kerberos对时钟偏差特别敏感，默认允许5分钟差异。一超，你看日志里全是KRB_AP_ERR_SKEW。那时候我还在想，明明密钥都是对的好好的，怎么就是验证不过去？后来想明白了——密钥本身没问题，但时效性被时间戳戳死了。
| 组件 | 角色 | 密钥同步方式 |
|---|---|---|
| KDC | 密钥分发中心 | 存储所有主体密钥 |
| Client | 请求服务的用户/机器 | 使用密码派生密钥与KDC交互 |
| Service | 提供网络服务 | 在KDC注册时注册密钥 |
| Ticket | 临时凭证 | 由KDC加密后发给Client |
TLS密钥同步原理
TLS的密钥同步过程，也就是我们常说的TLS握手。我每次给新人讲，都会画一个简单的流程——
- Client说：“我想用TLS连接你，支持这些算法。”
- Server回复：“好，我们用这个算法，这是我的证书（包含公钥）。”
- Client验证证书的合法性——检查CA签名、域名、有效期。
- 验证通过后，Client生成一个预主密钥（Pre-Master Secret），用Server的公钥加密发过去。
- Server用自己的私钥解密，拿到预主密钥。
- 两边各自用预主密钥和之前交换的随机数，计算出会话密钥。
这里有个关键点：TLS的密钥同步是在握手阶段完成的。证书携带的公钥只用来加密预主密钥，真正的通信采用会话密钥对称加密。这种方式的好处是，公钥虽然公开，但私钥只有Server有，中间人拿不到预主密钥，也就没法推导出会话密钥。
但我在生产环境里碰到过一个典型问题：证书链不完整。Server只发了自己的证书，没有把中间CA证书发过来。客户端的证书库里有根CA但没有中间CA，验证链断掉了。日志里报的错是certificate verify failed。你想想看，明明密钥对了，证书是好的，但就是连不上——因为缺少中间证书的“同步”。
核心要点：三种协议的密钥同步各有特点。
- SSH：直接传递公钥，需要手动确认或自动信任首次连接（TOFU）。
- Kerberos：通过可信第三方KDC完成密钥分发，用户不需要直接管理对方的公钥。
- TLS：基于PKI证书体系，通过CA链式信任完成密钥交换。
日志分析之所以对密钥同步这么重要，是因为这些过程一旦出问题，日志是最直接的线索。不管是SSH的Host key verification failed、Kerberos的KRB_AP_ERR_SKEW，还是TLS的certificate verify failed，都是从日志里读出来的。接下来我们会逐步深入，看看具体怎么从日志里定位这些故障。