先说一个我实际遇到的问题。有段时间我们内部的一个报表服务频繁报401日志里全是WWW-Authenticate: Negotiate前端同事第一反应是网关配置错了。排查到最后问题出在Kerberos认证的票据缓存上——某个定期任务运行时间超过了票据最长寿命后面的请求全部拿着过期票据去访问服务服务端验票失败才报的401。从那以后我开始认真把Kerberos这套机制吃透而不是一出问题就去重启网关。Kerberos认证本质上是一套“用票据代替密码”的分布式身份验证方案跟简单Token不同它把KDC当成可信第三方为客户端和服务端双向证明身份。不管你在做后端微服务接入、企业内部单点登录还是排查某个服务反复弹认证框的问题都会撞上它。这篇文章我会把Kerberos的协议环节、最小落地配置、常见故障串起来讲清楚争取让第一次接触的人也能顺着链路走通也让已经踩过坑的人知道下一步该往哪查。1. 为什么传统口令认证撑不住Kerberos才值得了解1.1 口令认证的三个老问题早期内部系统最常见的方式是客户端把用户名和密码交给服务端服务端拿去数据库比对。这个模型简单直接但生产环境里放大以后问题很明显密码在网络上传、重放攻击防不住、账号体系越来越乱。第一个问题是密码在网络上传。就算外层套了HTTPS一旦服务链路变长请求经过网关、负载均衡、消息中间件每一层都可能接触密码内容任何一层的日志如果把请求体原样打出来密码就跟着泄漏了。我在实际维护中见过不止一次服务本身没被攻破倒是某个代理组件的调试日志把登录请求完整打印了出来等于把所有人的口令都送了出去。第二个问题是重放。攻击者不用知道密码只要截获一次合法请求原样再发一遍服务端很难分辨是不是本人操作。早年不少内部系统就栽在这个简单的攻击上因为请求里缺少真正的“一次性”证据口令本身又被重复利用。第三个问题是账号疲劳。企业内部如果每个服务都各搞一套账号体系员工要记住几十组密码运维要维护几十张账号表还容易共用账号、弱口令、密码长期不换。这些问题叠加起来才是引入更规范认证方案的根本原因。1.2 票据思想把“密码证明”外包给可信第三方Kerberos的解决思路是你不需要在每个服务面前出示密码只需要向一个大家都信任的第三方也就是KDC证明一次自己的身份然后由第三方发一张票据你拿着票据去访问所有服务。类比一下演唱会验票。你入场时不会被逐个场馆要求出示身份证原件而是主办方统一验证一次身份给你发门票。每张票上有场次、时间、座位过期作废不对号入场安检就过不了。场馆不保存你的身份证资料只认票面信息。Kerberos里KDC就是主办方票据就是含有时效和会话密钥的凭证服务端就是场馆。有人会问为什么不直接用现成的Token或JWT方案Token体系在开放互联网上确实更常见但Kerberos有两个独到之处一是双向认证服务端也要向客户端证明“我确实是你想连的那台服务”防止假服务骗账号信息二是票据缓存与续期机制能实现一次登录、长期复用非常适合封闭可控的企业内网和数据中心场景。2. KDC里不止有密码长期密钥、两种票据、时间戳2.1 长期密钥怎么存、怎么用KDC是整个系统的信任锚点。它维护所有主体的长期密钥和策略信息。用户主体的长期密钥由口令派生出来本质上是一份口令哈希而不是口令明文服务主体的长期密钥则一般是kadmin随机生成的一长串随机数很少用人的口令代替这样就能避免服务账号跟着人的改密习惯走。KDC里的策略数据还包括每个主体是否允许预认证、票据最大生命周期、是否被禁用、是否要求双重身份验证等。这些配置都直接决定认证结果所以生产环境的KDC通常放在独立网络区域运维和审计都严格管控。如果KDC被攻破整个域里的票据都能被伪造加密链路再强也白搭。我见过有人把KDC和其他业务服务混部署在同一台虚拟机上省了机器却埋了雷属于典型的边界意识不足。另一个容易忽略的点KDC由于保存了所有用户的长期密钥等于持有一份全量口令哈希库。这类数据必须用独立的数据库文件管理而不是随手放进普通业务数据库。我们在做备份时也要把KDC数据单独加密备份文件的访问权限收紧到只有两三个运维人员能看到。2.2 TGT和服务票据一件事拆成两道门Kerberos里有两类票据很多新手一上来就混淆TGT和服务票据。TGT是“票据授予票据”解决的是“我有资格向KDC申请访问其他服务”这件事。用户通过AS阶段认证后拿到TGT里面装着客户端与TGS之间的会话密钥TGT本身用krbtgt主体域范围内的KDC服务主体的长期密钥加密普通用户解不开。拿到TGT之后用户就进入了一种“半认证”状态不需要每访问一个服务都重新输入密码。服务票据解决的是“我可以访问某个具体服务”这件事。用户拿TGT去TGS那里申请一个目标服务的票据这个票据用服务主体的长期密钥加密里面还放了一份客户端与服务端之间的会话密钥。服务票据是短命且面向单一服务的不会像TGT那样长期有效。可以这样记TGT是你的身份证原件服务票据是每个场馆单独发的入场券。你不需要把身份证原件交给每一个场馆只用入场券进场场馆也已经从主办方拿到了验票规则两者对上就能放行。2.3 时间戳为什么是Kerberos的隐形地基票据上带着开始时间和过期时间这个设计解决了“票据什么时候失效”的问题。更关键的是每次请求都会带一个认证器认证器里再压一个时间戳。这个时间戳用来对抗重放攻击只有新鲜的时间戳才会被接受旧的请求即使被截获重放到服务端时也会因为时间差过大被直接丢弃。代价就是全网时钟必须同步。Kerberos默认的时间容差一般是5分钟超过这个窗口就会出现随机性失败。注意这里的“随机性”很容易坑人上午正常、下午突然一部分请求失败过一会儿又好了很多人第一反应是网络抖动其实只是某台服务器的时钟在慢慢漂移。这也是后面故障章节第一个要查的东西。3. 把认证过程拉成一条线AS、TGS、AP三个阶段怎么衔接3.1 AS阶段密码没有明文进场只作为解密钥匙AS阶段的目标是用密码换取一张TGT。用户输入密码后客户端不会把密码明文发给KDC而是先用这个口令派生出一个长期密钥用这个密钥加密一段预认证数据里面包含时间戳和用户信息再把请求发给认证服务。KDC收到后先查用户主体是否存在、是否允许预认证然后在自己的数据库里找到对应用户的长期密钥解出预认证数据并检查时间戳。如果验证通过KDC就生成一张TGT并附带一个客户端与TGS之间的会话密钥整体响应再用用户的长期密钥加密后返回。客户端用自己的口令密钥解出响应拿到TGT和会话密钥。这一步做完用户就已经完成了一次“基于口令的证明”但口令本身只出现在本地派生密钥和解密响应的过程里没有在网络上传明文。实际使用时你敲下kinit命令能够成功、klist能看到一张TGT就说明AS阶段通过了。3.2 TGS阶段TGT只是一张“资格证”换服务票据才是目的用户不可能拿着一张TGT去直接访问具体业务因为目标服务根本解密不了TGT。真正干活前客户端还得向TGS发起一次请求申请目标服务对应的服务票据。这次TGS_REQ请求里包含两部分一是那张TGT二是用AS阶段拿到的会话密钥加密的新认证器。TGS收到后用自己的长期密钥解开TGT检查里面的主体信息和有效期再用会话密钥解开认证器验证时间戳。两者都对得上之后TGS会检查请求的服务主体SPN是否存在然后生成一张面向该服务主体的服务票据用服务主体的长期密钥加密同时再给客户端一份客户端与服务端之间的会话密钥。这一步在网络排错里最常见的问题就是SPN查不到。我后面会专门讲大小写和主机名的问题这里先记住结论TGS阶段的成败很大程度取决于请求里写的SPN能否和KDC里注册的主体的完全匹配。3.3 AP阶段服务端验票客户端验服务端拿到服务票据后客户端把它连同新认证器一起发给目标服务端。服务端用自己的长期密钥解开服务票据取出里面的会话密钥再用会话密钥解开认证器验证时间戳和客户端身份。如果验证通过客户端就被“放行”了。这里有个关键点服务端自始至终不知道用户密码也不需要知道。它只信任KDC用自己的长期密钥加密过的票据。只要票据能解出来、会话密钥能对上服务端就认为用户已经通过KDC认证。这是Kerberos比简单的“密码转交”方案安全很多的原因。可选情况下服务端还会回一个AP_REP用会话密钥加密一段信息证明“我确实知道这个会话密钥”。这样客户端也能确认自己连上的不是伪造的服务端。双端认证这个特性在数据中心里非常有用能防止内网中被劫持的服务欺骗客户端提交敏感信息。3.4 单点登录的体验来自票据缓存整个流程走完之后客户端的票据缓存里已经存了TGT和若干服务票据。后续再访问同一个服务时客户端会直接检查缓存里有没有对应的、仍然有效的服务票据有就直接用没有才拿TGT去TGS换新的。所以用户只需要登录一次之后访问其他服务时全程自动完成。不过这种“便利”也带来了运维上的麻烦票据缓存文件谁来管理、有效期多长、多进程共享时如何处理都必须有明确方案。我见过批处理任务因为共享同一个缓存文件一个进程执行了kdestroy清票其他正在跑的进程全部掉线。后面第5章我会专门展开。4. 最小可用的域环境搭建配置文件、principal与验证命令4.1 三个配置文件的分工别搞混搭建Kerberos环境常见的参考实现里主要有三类配置客户端和通用配置主要定义默认域、KDC地址、域名映射、加密类型和票据默认生命周期。KDC服务端配置定义数据库路径、支持的加密类型、票据最大生命周期和可续期总时长。服务端密钥表文件也就是keytab服务进程靠它解密服务票据里面不是明文密码而是一份长期密钥。下面是一份偏保守的客户端配置示例[libdefaults] default_realm EXAMPLE.COM dns_lookup_kdc true ticket_lifetime 8h renew_lifetime 7d forwardable true [realms] EXAMPLE.COM { kdc kdc1.example.com admin_server kdc1.example.com } [domain_realm] .example.com EXAMPLE.COM example.com EXAMPLE.COMKDC服务端配置里比较重要的是max_life和max_renewable_life。很多人图省事把max_life设成24小时甚至更长短期看是省了频繁kinit的麻烦长期看就是给票据泄露开了一个非常大的时间窗口。我建议max_life控制在8到10小时max_renewable_life设成7天让自动化任务有续期余地。配置项作用推荐值default_realm客户端默认使用的域EXAMPLE.COMticket_lifetime票据最长生命周期8hrenew_lifetime票据可续期总时长7ddns_lookup_kdc是否通过DNS查找KDCtrue4.2 创建主体与keytab服务端密钥要随机化KDC里每个用户和服务都有自己的主体记录。用户主体一般跟随真实账号服务主体则建议用随机密钥创建不要用人的口令。这样可以让服务端的长期密钥独立于任何人的密码密码被改掉也不会影响服务。常用的操作流程类似这样kadmin.local addprinc -randkey HTTP/service-host.example.com ktadd -k /etc/http.keytab HTTP/service-host.example.com-randkey的意思是让KDC生成一个随机密钥而不是从口令派生。生成keytab后务必把文件权限设成600并且只允许启动服务的账号读取。我在部署时见过有人图方便把keytab丢到/tmp下结果被其他服务进程读到等于把服务端身份拱手送人。服务进程需要配置“从哪里读取keytab”以及“使用哪个SPN”来接受认证。不同服务的接入方式不同但底层逻辑都一样进程启动后加载keytab里的长期密钥备好解密服务票据。4.3 kinit、klist、kvno三板斧验证配置完之后先用最简单的三条命令把链路验证一遍kdestroy kinit user01EXAMPLE.COM klist kvno HTTP/service-host.example.comkinit成功说明AS阶段通过也就是KDC认识这个用户、口令派生密钥能解开响应klist能看到TGT的签发时间和到期时间kvno会去请求一次目标服务的票据并返回版本号能拿到版本号就说明TGS阶段到SPN解析都正常。真正访问业务时的AP阶段还需要看具体服务日志但到这里网络链路、KDC可达性、SPN注册、票据生命周期都已经过了一遍问题基本能定位一半。如果kvno报错注意看错误码落在哪个阶段是KDC查不到用户、SPN不存在还是时间戳超出容差。不同阶段的错误码对应完全不同的排查方向别一上来就怀疑防火墙。5. 真实环境最容易翻车的三类故障5.1 时钟偏移导致的“三元失败”症状看起来很像网络抖动一段时间内请求随机失败错误日志里出现KDC_ERR_PREAUTH_FAILED或KRB_AP_ERR_SKEW。过一会儿又自己恢复了因为另一台机器的时钟又漂回了容差窗口。根因只有一个Kerberos对时间非常敏感默认容差5分钟。实际运维中最常见的诱因是虚拟机休眠恢复后时钟没有自动校准或者新扩容节点忘了配时间同步。我处理过的一个典型案例是某台虚拟机的宿主时间不准容器里的服务全部跟着偏移整批请求被KDC拒绝。解法很简单但必须覆盖所有节点所有客户端、服务端和KDC统一用NTP或chrony做时间同步同一域内尽量使用同一时间源。别只在KDC上做同步客户端节点不同步照样翻车。5.2 SPN大小写和主机名引发的“明明有权限却验不过”症状是同一套权限配置某个服务从A系统访问正常从B系统访问就报KDC_ERR_S_PRINCIPAL_UNKNOWN。重试无数次都一样权限也没问题最后发现是请求的SPN和KDC里注册的SPN大小写不一致。Kerberos的SPN匹配是大小写敏感的。比如KDC里注册的是HTTP/file-node01.internalEXAMPLE.COM客户端请求时写成了http://File-Node01.internalTGS就会发现目标主体不存在直接返回错误。很多服务在生成SPN时会自动拼接主机名而主机名的来源可能是配置文件、环境变量、反向DNS结果每一条链路的大小写写法不一样坑就出来了。统一做法是所有服务配置里使用全小写的完整限定域名禁止在部分地方用短主机名、部分地方用全限定名。主机名的确需要别名时也要在KDC里把对应SPN一并注册齐全而不是指望大小写兼容。5.3 票据过期、缓存覆盖和长任务掉票第三个高频故障是时间维度的问题任务跑到一半突然认证失败手动跑同样的命令却一切正常。原因通常是任务启动时用kinit拿了一张票据但任务本身的执行时间超过了票据生命周期或者多个进程共享同一个票据缓存文件一个进程刷新票据、另一个进程销毁票据导致彼此覆盖。Apache类服务的长连接也可能持有过期票据服务端验票后才会发现票早已失效。解决思路有三条长任务使用可续期的票据并封装续期逻辑定期刷新缓存每个独立任务尽量使用独立的缓存目录避免共享服务端和客户端都要正确配置票据生命周期不要单边拍脑袋改参数。我比较推荐的方式是让批处理任务在每次访问前检查缓存剩余时间剩余不足时主动kinit刷新而不是等到访问报错才处理。错误码含义优先检查点KDC_ERR_PREAUTH_FAILED预认证失败密码是否正确、时钟是否偏移KDC_ERR_S_PRINCIPAL_UNKNOWN目标服务主体不存在SPN名称、大小写、域名是否正确KRB_AP_ERR_TKT_EXPIRED票据过期ticket_lifetime、缓存状态KRB_AP_ERR_MODIFIED票据被修改或密钥不匹配keytab是否正确、KVNO是否一致KRB_AP_ERR_SKEW时间戳偏移超容差NTP同步、时区配置6. 长期运维里我沉淀下来的三条经验6.1 票据生命周期8小时加7天续期比24小时好用我见过很多人为了减少认证报错把票据最长生命周期一路调到24小时甚至更长。短时间看确实省事但风险在于票据和密码一样有效期越长泄露后的可利用窗口越大。生产环境里我坚持用8小时主生命周期加7天可续期总时长的组合。这里的关键是“续期”和“重新认证”的区别。续期只延长一张票据的到期时间不需要用户重新输入密码非常适合批处理任务。重新认证则要重新走一遍口令派生或密钥验证流程安全级别更高但体验更重。合理配置下大多数场景可以做到“用户一天只登录一次长任务自动续期不中断”同时把长期有效的秘密控制在最小数量。6.2 委派和最小权限别让A服务能代表所有用户访问所有服务当一个服务需要代替用户去访问另一个服务时就会牵扯到委派。Kerberos里的委派功能很强大但也最容易滥用。全量转发式的委派一旦放开等于A服务拥有了“代表域内所有用户访问任意服务”的能力一旦A服务被攻破后果不堪设想。我的建议是能不用委派就不用必须用的时候优先选受限委派明确指定允许转发的目标服务和目标主体而不是开放整个域。服务账号单独建、单独授权别把通用管理员账号拿来当服务运行账号。权限本身越小票据能访问的范围就越小出问题时的爆炸半径也越小。6.3 遇到Kerberos问题的固定排查顺序踩过足够多坑之后我给自己定了一套排查顺序每次都能快速收敛问题而不是东一下西一下乱试。先看报错码属于哪一阶段AS阶段看用户主体和密码TGS阶段看TGT和SPNAP阶段看keytab和票据。再检查全链路时间同步这是开销最小但最常见的问题来源。然后核对SPN大小写和主机名紧接着查客户端klist里票据状态和有效期最后才是升级到抓包或协议日志看具体的AS_REQ、TGS_REQ、AP_REQ往返。我自己的体会是Kerberos协议历史悠久文档读起来也比较绕但把AS、TGS、AP三个阶段吃透之后绝大多数生产故障都能归类到时间、名字、密钥这三个维度里。每次调整keytab或SPN后务必确认服务进程重新加载了密钥很多“为什么改了还是不行”的问题就差在这最后一件事上。