Kerberos 入门与常用操作浅析

痛定思痛。 2022-11-03 10:47 98阅读 0赞

### . ###

*  一 .前言
 *  二 .Kerberos认证流程
 *  三 .Kerberos Principal
 *  四 .Kerberos的优点和不足
 *   *  4.1. 优点
     *  4.2. 不足
 *  五. KDC常用操作
 *  六.Client常用操作

# 一 .前言 #

> Kerberos协议是 一种计算机网络授权协议， 用于在非安全的网络环境下对个人通信进行加密认证。

Kerberos 通过定义**用户** 和 **服务端**所使用的认证身份 (Principal) 来进行访问控制， 用户通过 Kerberos 客户端使用自己的 **Principal** 向**认证服务器**进行 身份的认证， 认证成功后服务器会将表示用户身份的票据 (**Ticket**) 返回用户， 在之后的通信过程中 Kerberos 客户端使用己认证的票据进行安全的通信.

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70]

*  名词解释

1.  KDC : Key Distribution Center, 即 密钥分发中心 。
2.  Database : 数 据库， 用 于存放用户和 服 务 的 记 录， Kerberos的数 据库中使用Principal来命名和引用 一条记录。
    
        Kerberos数据库中的记录包含以下内容：
         	·记录所关联的Principal。
         	·加密密钥和相关的KVNO。
         	·与Principal关联的票据的最长有效期。
         	·与Principal关联的票据的最长更新周期。
         	·描述票据的参数或标志。
         	·密码过期时间 。
         	·Principal的过期时间
3.  Application Server :应用服务器
4.  Client: 客户机
5.  AS: Authentication Service, 认证服务。
6.  TGS : Ticket Granting Service, 票据授权服务。
7.  ST: Service Ticket, 服务票据， 由 KDC 的 TGS 发放 ， 任何一个应用 (Application)都需要一张有效的服务票据才能访问。
8.  TGT : Ticket Granting Ticket, 票据授权票据， 由 KDC 的 AS 发放。 TGT 具有一定的有效期， 到期后需要更新来续约。
9.  Ticket :票据。 票据是客户端提交给应用服务器用千证明其身份真实性的。票据由认证服务器颁发， 并使用所需要的服务端密钥加密。
10. KVNO : Key Version Number, 密钥版本号。 当用户更改密码或管理员更新应用服务器的密钥时． 这种修改将会使版本号增加。

# 二 .Kerberos认证流程 #

Kerberos由三部分构成: **Kerberos服务器KDC（秘钥分发中心）**、**客户机(Client)** 和 \*\*应用服务器( Application Server)\*\*组成，

其中KDC包含了 **Authentication Service**和**Ticket Granting Service**两种服务。

1.  **Authentication Service：** **授权服务 , 简称AS**(Authorization Server)，对于上面流程1，提供初始授权认证，用户表明需求并使用密码对请求进行加密，AS用提供的密码对请求进行解密后得到请求内容，返回给用户一个TGT（ticket granting tickets)(用一个秘钥加密)
2.  **Ticket Granting Service** : **鉴权服务,简称TGS**(Ticket Granting Server) . 用户得到TGT后使用TGT去访问TGS( Ticket Granting Server ),TGS验证TGT后（使用秘钥解密）返回一个Ticket给用户，得到ticket后去访问server，server收到ticket和KDC进行验证，通过后提供服务

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70]

*  数据包内容

1.  **AS\_REQUEST**: AS\_REQUEST是最初的 用户认证请求， 由 kinit 命令生成。 这个信息指向KDC 中的 授权服务\[AS\]服务。
2.  **AS\_REPLY**: AS\_REPLY 是 授权服务\[AS\]对先前请求的答复 ， 它主要包含 TGT（使用 TGS 密钥加密） 和会话密钥 SK\_TGS（使用请求认证的用户密钥加密）。
3.  **TGS\_REQUEST** : TGS\_REQUEST是客户端向 票据授权服务\[TGS\]请求服务票据 (ST) 的请求包。 这个数据包包含了之前的 TGT 数据以及一个由会话密钥加密过的客户端身份凭证。
4.  **TGS\_REPLY**: TGS\_REPLY 是 票据授权服务\[TGS\]对之前请求的答复。 其中包含了客户端所请求的服务票据（使用服务密钥加密） 以及一个由 票据授权服务\[TGS\]生成的会话密钥 SK\_Service（使用之前 授权服务\[AS\]生成的会话密钥加密）。
5.  **AP\_REQUEST**: AP\_REQUEST是客户端发送给应用服务器用于使用服务的请求。 其中包含了之前从 TGS 服务请求到的服务票据以及由客户端生成的身份凭证， 但这次使用由 TGS 生成的会话密钥 (SK\_Service) 加密。
6.  **AP\_REP**: AP\_REP 由应用服务器发送给客户端， 证明自己确实是用户所请求的服务端。 这个数据包是**可选**的， 只有在使用了相互认证机制时客户端才会请求这个数据包。

*  认证流程

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70]

1.  **客户端向 KDC 中的 授权服务\[AS\]发送 AS\_REQUEST请求身份验证**， 授权服务\[AS\]返回 AS\_REPLY,其中包括为用户和 TGS 生成的一个会话密钥 SK\_TGS, 并发送使用用户密钥加密的 TGT 、SK\_TGS。  
    这个请求验证的过程实际上是使用 kinit 命令来完成的， kinit 将用户名传给 授权服务\[AS\]，授权服务\[AS\]查找用户名的密码， 将 TGT 和 SK\_TGS 使用用户密码加密后发送给 kinit, 如rut 要求用户输入密码， 解密后得到 TGT 和 SK。 其中， **TGT 使用 授权服务\[TGS\] 的密钥加密**。
2.  **客户端向 KDC 中的 授权服务\[TGS\]发送 TGS\_REQUEST, 请求访问某个应用服务器的服务票据 (ST)， 发送 TGT 和身份凭证 (Authenticator)**。  
    其中， 身份凭证用于验证发送该请求的用户就是 TGT 中所声明的， **身份凭证是使用 授权服务\[TGS\] 和用户之间的会话密钥 SK 加密**的， 防止 TGT 被盗。 授权服务\[TGS\] 先使用自己的密钥解开TGT, 获得它与用户之间的会话密钥， 然后使用 SK 解密身份凭证， 验证用户和有效期。
3.  **TGS 判断无误后， 为用户和应用服务器之间生成一个新的会话密钥:SK\_Service,然后发送 TGS\_REPLY 给用户**， 其中包括 SK\_Service 和服务票据 (ST) 。其中， **服务票据是使用应用服务器的密钥加密的**， SK\_Service 使用 授权服务\[TGS\] 和用户之间的会话密钥 (SK\_TGS) 加密的。
4.  **用户使用与 授权服务\[TGS\] 之间的会话密钥 SK\_TGS 解开包得到与应用服务器之间的会话秘钥 SK\_Service, 然后使用 SK\_Service 生成一个身份凭证 ( Authenticator)， 向应用服务器发送 AP\_REQUEST, 其中包括服务票据 (ST) 和身份凭证**。其中， 此处的身份凭证是使用用户和应用服务器之间的会话密钥 (SK\_Service) 加密的， 应用服务器收到后先使用服务器的密钥解密服务票据 (ST)， 或者会话密钥 ( SK\_Service)， 然后使用会话密钥 (SK\_Service) 解密身份凭证 ( Authenticator) 来验证发送请求的用户就是票据中所声明的用户。
5.  **应用服务器向用户发送一个数据包 AP\_REPLY, 以证明自己的身份**， 这个包使用会话密钥 (SK\_Service) 加密。 客户端会等待应用服务器发送确认信息， 如果不是正确的应用服务器， 就无法解开 ST, 也就无法获得会话密钥， 从而避免用户使用错误的服务器。  
    此后用户与应用服务器之间使用 SK\_Service 进行通信， 且在 TGT 有效期内， 用户将跳过第 1 步的身份验证， 直接从第 2步使用 TGT 向 TGS 证明自己的身份。

# 三 .Kerberos Principal #

> 通常Principal的命名格式为Name/lnstance@Realm。

其中Name代表了用户名或主机名，Instance。Instance可以省略， 在未省略的情况下需要与Name使用""/ 号隔开。

Kerberos principal（又称为主体）用于在kerberos加密系统中标记一个唯一的身份。主体可以是**用户**（如 老牛）或**服务**（如namenode或hive）。

根据约定，主体名称分为三个部分：

> 主名称、实例和领域。例如，典型的Kerberos主体可以是hdfs/admin@EXAMPLE.COM。在本实例中：

*  hdfs 是**主名称**。主名称可以是此处所示的用户名或namenode等服务。
 *  admin是**实例**。\*\*是对Name指代用户或主机的进一步描述， 可以是用户所在的主机或类型等信息 . \*\*对于用户主体，实例是可选的；但对于服务主体，实例则是必需的。
    
        例如，如果用户 joe 有时充当系统管理员，则他可以使用 joe/admin 将其自身与平时的用户身份区分开来。同样，如果 joe 在两台不同的主机上拥有帐户，则他可以使用两个具有不同实例的主体名称，例如 joe/node1.example.com 和 joe/node2.example.com。
          请注意，Kerberos 服务会将 joe 和 joe/admin 视为两个完全不同的主体。
          对于服务主体，实例是全限定主机名。例如，node1.example.com就是这种实例。
 *  EXAMPLE.COM是Kerberos领域。

**Hadoop中的每个服务和子服务都必须有自己的主体**。给定领域中的主体名称由主名称和实例名称组成，在这种情况下，实例名称是运行该服务的主机的FQDN。**由于服务未使用密码登录以获取其票证，因此其主体的身份验证凭据存储在keytab密钥表文件中，该文件从Kerberos数据库中提取并本地存储在服务组件主机上具有服务主体的安全目录中**。  
比如NameNode组件在node1.example.com主机上，启用kerberos之后，会自动生成nn.service.keytab文件，并存储在/etc/security/keytabs目录下，用户所有者是hdfs:hadoop，权限为400  
![在这里插入图片描述][20210227200723284.png]

> FQDN：(Fully Qualified Domain Name)全限定域名：同时带有主机名和域名的名称。

*  Principal和Keytab命名约定

<table> 
 <thead> 
  <tr> 
   <th align="left"></th> 
   <th align="left">管理</th> 
   <th align="left">示例</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">Principals</td> 
   <td align="left">FQDN@EXAMPLE.COM</td> 
   <td align="left">nn/node1.example.com@EXAMPLE.COM</td> 
  </tr> 
  <tr> 
   <td align="left">Keytabs</td> 
   <td align="left">$service_component_abbreviation.service.keytab</td> 
   <td align="left">/etc/security/keytabs/nn.service.keytab</td> 
  </tr> 
 </tbody> 
</table>

请注意前面的示例中每个服务主体的主名称。这些主要名称（例如nn或hive）分别代表NameNode或Hive服务。  
每个主要名称都附加了实例名称，即运行它的主机的FQDN。

此约定为在多个主机（如DataNodes和NodeManager）上运行的服务提供唯一的主体名称。

添加主机名用于区分，例如，来自DataNode A的请求与来自DataNode B的请求。这一点很重要，原因如下：

> 1.  一个 DataNode 的受损 Kerberos 凭据不会自动导致所有 DataNode 的 Kerberos 凭据受损。
> 2.  如果多个 DataNode 具有完全相同的主体并同时连接到 NameNode ，并且正在发送的 Kerberos 身份验证器恰好具有相同的时间戳，则身份验证将作为重播请求被拒绝。

# 四 .Kerberos的优点和不足 #

## 4.1. 优点 ##

> 较高的Performance

Kerberos是一个涉及到3方的认证过程：Client、Server、KDC。但是一旦Client获得用过访问某个Server的Ticket，该Server就能根据这个Ticket实现对Client的验证，而无须KDC的再次参与。和传统的基于Windows NT 4.0的每个完全依赖Trusted Third Party的NTLM比较，具有较大的性能提升。

> 实现了双向验证（Mutual Authentication）

传统的NTLM认证基于这样一个前提：Client访问的远程的Service是可信的、无需对于进行验证，所以NTLM不曾提供双向验证的功能。这显然有点理想主义，为此Kerberos弥补了这个不足：Client在访问Server的资源之前，可以要求对Server的身份执行认证。

> 对Delegation的支持

Impersonation和Delegation是一个分布式环境中两个重要的功能。Impersonation允许Server在本地使用Logon 的Account执行某些操作，Delegation需用Server将logon的Account带入到另过一个Context执行相应的操作。NTLM仅对Impersonation提供支持，而Kerberos通过一种双向的、可传递的（Mutual 、Transitive）信任模式实现了对Delegation的支持。

> 互操作性（Interoperability）

Kerberos最初由MIT首创，现在已经成为一行被广泛接受的标准。所以对于不同的平台可以进行广泛的互操作。

## 4.2. 不足 ##

*  Kerberos 存在单点失败的问题, 解决方案: 复合 Kerberos 服务器 或者 后备认证机制 .
 *  Kerberos身份认证采用的是对称加密机制，加密和解密使用的是相同的密钥，交换密钥时的安全性比较难以保障。
 *  时间同步 . Kerberos认证机制中， 认证服务器要求所有参与的主机时间同步。同时， 票据存在有效期， 如果客户端与服务端的时钟不同步 ， 则会导致认证失败。
 *  Kerberos服务器与用户共享的服务会话密钥是用户的口令字，服务器在响应时不需验证用户的真实性，而是直接假设只有合法用户拥有了该口令字。如果攻击者截获了响应消息，就很容易形成密码攻击。
 *  Kerberos中的AS（身份认证服务）和TGS是集中式管理，容易形成瓶颈，系统的性能和安全也严重依赖于AS和TGS的性能和安全。在AS和TGS前应该有访问控制，以增强AS和TGS的安全。
 *  随用户数量增加，密钥管理较复杂。Kerberos拥有每个用户的口令字的散列值，AS与TGS负责户间通信密钥的分配。假设有n个用户想同时通信，则需要维护n×（n-1）/2个密钥。
 *  krbtgt是KDC的服务账户， 在每一个Realm中都存在一个 krbtgt账户。krbtgt账户用来创建TGT的加密密钥。在Kerberos的认证机制中， 使用 krbtgt生成的密钥来加密TGT,因此理论上只有两方能够解密TGT, 而只要能够正确地解密TGT, Kerberos就会认为其中的信息是可信的。  
    在这个前提下， Kerberos中的 krbtgt账户是唯一一个密码不会自动更新的账户， 只有在主机进行灾害恢复， 或作用域进行功能升级导致账户变动时才会更新。因此在长期使用的情况下， 如果krbtgt的账户密码被盗取， 则可能会产生严重的安全问题。

# 五. KDC常用操作 #

1.  kadmin.local:打开KDC控制台， 需要 root权限。
2.  \[ addprinc \]：添加Principal, 在KDC控制台使用， 执行后需要两次输入该Principal的密码。
3.  \[delprinc \]：删除Principal, 在KDC控制台使用， 执行后需要确认是否删除。
4.  \[xst -k \] ： 导出指定Principal到指定 Keytab文件， 在KDC控制台使用。 如果指定的Keytab文件已存在， 则会将指定Principal信息合并至 Keytab文件中。
5.  \[modprinc - \]：针对指定的Principal进行某项参数的修改， 在KDC控制台使用。 需要注意的是， 使用 modprinc命令修改的参数，优先级会比kdc.conf中的高。
6.  \[getprinc \]： 查 看指 定Principal的 信 息， 包括每种密 钥的加 密类型、KVNO标签等， 在KDC控制台使用。
7.  \[listprincs\]：列出所有Principal, 在KDC控制台使用。

# 六.Client常用操作 #

1.  klist:列出当前系统用户的 Kerberos认证情况。
2.  klist -kt ：列出指定 keytab文件中包含的Principal信息， 需要该文件的读权限。
3.  kinit ：使用输入密码的方式认证指定的Principal。
4.  kinit -kt ：使用指定 keytab中的指定Principal进行认证， 需要该文件的读权限。
5.  kdestory:注销当前已经认证的Principal。
6.  ktutil:进入 keytab工具控制台。
7.  \[list\] \[1\]：列出当前 ktutil中的密钥表。
8.  \[clear\] \[clear\_list\]：清除当前密钥表。
9.  \[rkt <keytab file path>\]：读取一个keytab中的所有Principal信息到密钥表， 需要有该文件的读权限 ， 在ktutil中使用。
10. \[wkt <keytab file path>\]：将密钥表中的所有Principal信息写入指定文件中。 如果文件已存在， 则需要该文件的写权限， 信息会附加至文件末， 在ktutil中使用。
11. \[addent -password -p <principal> -k -e \] ： 手 动 添 加一条Principal信息到密钥表 ， 执行后需要输入指定Principal的密码。 由于手动添加的信息 ktutil不会进行验证， 因此不推荐使用。
12. \[delent <entity number>\]：从密钥表中删除指定行号的Principal信息， 行号可使用list或l命令查看， 在ktutil中使用。
13. \[Ir\] \[Iist\_request\]：列出所有 ktutil中可用的命令， 在ktutiJ中使用。
14. \[quit\] \[q\] \[exit\]：退出ktutil控制台。

参考链接 : https://juejin.cn/post/6844903955416219661

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70]: /images/20221024/c9af86a6c3a94885ac5fff591f9ba790.png
[20210227200723284.png]: /images/20221024/e68bc7a1d8ea4fad8a23c3807927033b.png