Kerberos 认证协议解析

showyoui
0 阅读7分钟

概述

Kerberos 是一种基于对称密钥加密技术的网络认证协议，专为 C/S 架构提供高强度的身份验证。它由麻省理工学院（MIT）设计，其名字来源于希腊神话中的三头犬 Cerberus，形象地代表了其认证模型中的三方：客户端（Client）、服务端（Server）以及作为可信第三方的密钥分发中心（KDC）。在 Kafka、Hadoop 等分布式系统中，Kerberos 是实现安全认证的主流方案。

核心概念

Kerberos 的世界由以下几个核心角色构成：

  • KDC (Key Distribution Center): 密钥分发中心，是整个认证体系的核心。它本身由两个逻辑部分组成：

    • AS (Authentication Server): 认证服务，负责验证 Client 的初始身份，并发放 TGT。

    • TGS (Ticket Granting Server): 票据授予服务，负责在 Client 持有 TGT 的前提下，发放用于访问具体服务的票据。

  • Principal (主体): 任何参与认证的实体。每个 Principal 都有一个唯一的身份标识，例如 user/host@REALM。主要分为两类：

    • 用户主体: 需要访问服务的用户或客户端。

    • 服务主体: 提供特定服务的应用或服务器，例如 kafka/kafka-broker-1.example.com@EXAMPLE.COM。

  • Ticket (票据): KDC 颁发给客户端的凭证，用于证明其身份。

  • TGT (Ticket Granting Ticket): "票据的票据"，客户端从 AS 获取，用于向 TGS 证明自己的身份，以换取访问具体服务的票据。

  • Service Ticket: 服务票据，客户端从 TGS 获取，用于向最终的目标服务证明自己有权访问。

认证流程

Kerberos 的认证过程可以看作是客户端“过三关”的过程，最终目的是拿到可以和服务直接通信的“令牌”。

workflow.png

阶段一：Client -> AS，获取 TGT

这是客户端的“敲门”步骤，目的是向 KDC 证明“我是我”。

  1. 认证请求: 客户端向 AS 发送一个包含自己 Principal 名称的明文请求。请求中还包含一个用客户端密码的哈希值（即客户端密钥）加密的时间戳。注意：用户的明文密码永远不会在网络上传输。

  2. AS 验证与响应:

  • AS 在其数据库中查找该客户端的密钥。
  • 用该密钥尝试解密请求中的时间戳。如果成功，说明客户端身份合法。
  • 验证通过后，AS 返回两样东西：
  • TGT: 这张票据包含了客户端信息、TGS 会话密钥等，但它是用 TGS 的密钥加密的。客户端无法解开它，只能当个信物。
  • Client/TGS 会话密钥: 这个密钥是用客户端自己的密钥加密的。
  1. 客户端解密: 客户端收到响应后，用自己的密码哈希解密，得到 Client/TGS 会话密钥。至此，客户端拥有了 TGT 和与 TGS 通信的会话密钥。

阶段二：Client -> TGS，获取服务票据

客户端拿着第一阶段的成果，去向 TGS 申请访问某个具体服务的“门票”。

  1. 服务票据请求: 客户端向 TGS 发送请求，包含：

  • 第一阶段获取的 TGT。

  • 需要访问的服务的 Principal 名称。

  • 一个认证器 (Authenticator)，包含客户端信息和时间戳，用第一阶段获取的 Client/TGS 会话密钥加密。

  1. TGS 验证与响应:

  • TGS 用自己的密钥解密 TGT，拿到里面的 Client/TGS 会话密钥。

  • 用这个会话密钥解密认证器，验证客户端身份和请求的有效性（防重放）。

  • 验证通过后，TGS 返回两样东西：

  • 服务票据 (Service Ticket): 包含客户端信息、新的会话密钥等，但这次是用目标服务的密钥加密的。客户端同样无法解开。

  • Client/Server 会话密钥: 这个新密钥是用 Client/TGS 会话密钥加密的。

  1. 客户端解密: 客户端用第一阶段的会话密钥解密，得到用于和目标服务通信的 Client/Server 会话密钥。

阶段三：Client -> Server，请求服务

万事俱备，客户端现在可以拿着“门票”去找真正的服务了。

  1. 服务请求: 客户端向目标服务发起请求，包含：

  • 第二阶段获取的服务票据。

  • 一个新的认证器，用第二阶段获取的 Client/Server 会话密钥加密。

  1. 服务验证与响应:

  • 目标服务用自己在 KDC 注册的密钥解密服务票据，拿到 Client/Server 会话密钥。

  • 用这个会话密钥解密认证器，验证客户端身份。

  • 验证通过后，服务确认客户端合法，开始提供服务。（可选）服务可以向客户端回送一个响应，证明自己也是合法的，实现双向认证。

核心安全机制

  • 密钥隔离: 用户的密码哈希只用于和 AS 的初次交互。后续流程都使用临时的会话密钥，且每个会话密钥都有特定的用途和生命周期，大大降低了密钥泄露的风险。
  • 防重放攻击: 认证器 (Authenticator) 中包含时间戳，且只能使用一次。服务会缓存近期收到的认证器信息，防止攻击者截获并重放请求。
  • 时间戳与时钟同步: Kerberos 强依赖时间同步。如果客户端和服务端的时钟偏差过大（默认5分钟），认证会失败。这是防止票据被长时间持有和重放的关键机制，也是运维中常见的“坑”。

优缺点分析

优势

  1. 强安全性: 密码不经过网络传输，认证过程基于加密票据，有效防止窃听。
  2. 单点登录 (SSO): 用户只需登录一次，就可以在 TGT 的生命周期内（如8小时）无缝访问授权的多个服务。
  3. 双向认证: 不仅客户端要验证服务端，服务端也要验证客户端，防止客户端连接到伪造的服务。
  4. 互操作性: 作为广泛应用的标准协议 (RFC 4120)，可以集成各种系统。

局限性

  1. 单点故障 (SPOF): KDC 是认证核心，一旦宕机，整个认证体系都会瘫痪。因此生产环境必须部署高可用的 KDC 集群。

  2. 严格的时钟同步: 对集群内所有节点的时钟同步要求极高，是部署和维护时最需要注意的一点。

  3. 部署复杂: 相比简单的用户名/密码认证，Kerberos 的部署和密钥管理（keytab 文件）更复杂。

  4. 初始密钥分发: 需要一个安全的方式来分发服务端的 keytab 文件。

实践与排错

关键配置 (krb5.conf)


# /etc/krb5.conf 示例

[libdefaults]

default_realm = EXAMPLE.COM # 默认的 Realm

dns_lookup_realm = false

dns_lookup_kdc = false

ticket_lifetime = 24h

renew_lifetime = 7d

forwardable = true

[realms]

EXAMPLE.COM = {

kdc = kdc-server.example.com

admin_server = kdc-server.example.com

}

[domain_realm]

.example.com = EXAMPLE.COM

example.com = EXAMPLE.COM

常用命令


# 申请 TGT (交互式输入密码)

kinit username@EXAMPLE.COM

# 使用 keytab 文件为服务主体申请 TGT (非交互式)

kinit -kt /path/to/service.keytab service/hostname@EXAMPLE.COM

# 查看当前缓存的票据

klist

# 销毁当前缓存的票据

kdestroy

常见错误与排查思路

  • Clock skew too great: 客户端与 KDC 或目标服务的时钟不同步。检查所有节点的 ntp 服务。

  • Client not found in Kerberos database: 客户端 Principal 不存在。检查拼写或是否已在 KDC 中创建。

  • Pre-authentication failed: 通常是密码错误。

  • Ticket expired: 票据已过期。需要重新 kinit。

  • GSSException: No valid credentials provided: 客户端没有可用的 TGT，或者 TGT 已过期。检查 klist。

总结

Kerberos 是一个强大而成熟的认证协议，通过“票据”机制在不信任的网络环境中实现了安全的身份认证。虽然它的部署和维护有一定复杂度，并且对时钟同步有严格要求，但其带来的高安全性、单点登录等特性，使其在企业级分布式系统（如 Kafka、Hadoop、Active Directory）中成为事实上的标准。理解其核心流程和概念，是保障这些系统安全稳定运行的关键。

avatar
文章
阅读
粉丝