Kerberosr认证流程、配置介绍及手动部署、问题排查方向-优快云博客

本文链接：https://blog.youkuaiyun.com/whutmengmeng/article/details/142215500

前言

Kerberos协议是一个专注于验证通信双方身份的网络协议，不同于其他网络安全协议的保证整个通信过程的传输安全，Kerberos侧重于通信前双方身份的认定工作，帮助客户端和服务端解决“证明我自己是我自己”的问题，从而使得通信两端能够完全信任对方身份，在一个不安全的网络中完成一次安全的身份认证继而进行安全的通信。

1 Kerberos工作原理

Kerberos协议中存在三个角色：

客户端（client）：发送请求的一方
服务端（Server）：接收请求的一方
密钥分发中心（Key Distribution Center，KDC），而密钥分发中心一般又分为两部分，分别是：
AS（Authentication Server）：认证服务器，专门用来认证客户端的身份并发放客户用于访问TGS的TGT（票据授予票据）
TGS（Ticket Granting Ticket）：票据授予服务器，用来发放整个认证过程以及客户端访问服务端时所需的服务授予票据（Ticket）

在整个kerberos认证过程中，三个角色缺一不可

Kerberos认证流程，基本上分为两大步。第一步，客户端向KDC请求获得他想要访问的服务的服务授予票据（可以想象成去动物园，想去买一张能够进入动物园的门票）。第二步，拿着这张服务授予票据（Ticket）去访问服务端的服务。

而细化整个认证过程，可以分为三次通信，接下来将分别解释每一次通信的过程。

第一次通信

为了获得能够用来访问服务端服务的票据，客户端首先需要来到KDC获得服务授予票据（Ticket）。由于客户端是第一次访问KDC，此时KDC也不确定该客户端的身份，所以第一次通信的目的为KDC认证客户端身份，确认客户端是一个可靠且拥有访问KDC权限的客户端，过程如下：

① 客户端用户向KDC以明文的方式发起请求。该次请求中携带了自己的用户名，主机IP，和当前时间戳；
② KDC当中的AS（Authentication Server）接收请求（AS是KDC中专门用来认证客户端身份的认证服务器）后去kerberos认证数据库中根据用户名查找是否存在该用户，此时只会查找是否有相同用户名的用户，并不会判断身份的可靠性；
③ 如果没有该用户名，认证失败，服务结束；如果存在该用户名，则AS认证中心便认为用户存在，此时便会返回响应给客户端，其中包含两部分内容：

第一部分内容称为TGT，也叫做票据授予票据，客户端需要使用TGT去KDC中的TGS（票据授予中心）获取访问网络服务所需的Ticket（服务授予票据），TGT中包含的内容有kerberos数据库中存在的该客户端的Name，IP，当前时间戳，客户端
即将访问的TGS的Name，TGT的有效时间以及一把用于客户端和TGS间进行通信的Session_key(CT_SK)。整个TGT使用TGS密钥加密，客户端是解密不了的，由于密钥从没有在网络中传输过，所以也不存在密钥被劫持破解的情况。
第二部分内容是使用客户端密钥加密的一段内容，其中包括用于客户端和TGS间通信的Session_key(CT_SK),客户端即将访问的TGS的Name以及TGT的有效时间，和一个当前时间戳。该部分内容使用客户端密钥加密，所以客户端在拿到该部分内容时可以通过自己的密钥解密。如果是一个假的客户端，那么他是不会拥有真正客户端的密钥的，因为该密钥也从没在网络中进行传输过。这也同时认证了客户端的身份，如果是假客户端会由于解密失败从而终端认证流程。

至此，第一次通信完成。

第二次通信

此时的客户端收到了来自KDC（其实是AS）的响应，并获取到了其中的两部分内容。此时客户端会用自己的密钥将第二部分内容进行解密，分别获得时间戳，自己将要访问的TGS的信息，和用于与TGS通信时的密钥CT_SK。首先他会根据时间戳判断该时间戳与自己发送请求时的时间之间的差值是否大于5分钟，如果大于五分钟则认为该AS是伪造的，认证至此失败。如果时间戳合理，客户端便准备向TGS发起请求，其次请求的主要目的是为了获取能够访问目标网络服务的服务授予票据Ticket（进入动物园需要的门票）。在第二次通信请求中，客户端将携带三部分内容交给KDc中的TGS，第二次通信过程具体如下所述：

客户端行为：
① 客户端使用CT_SK加密将自己的客户端信息发送给KDC，其中包括客户端名，IP，时间戳；
② 客户端将自己想要访问的Server服务以明文的方式发送给KDC；
③ 客户端将使用TGS密钥加密的TGT也原封不动的也携带给KDC；
TGS行为：
① 此时KDC中的TGS（票据授予服务器）收到了来自客户端的请求。他首先根据客户端明文传输过来的Server服务IP查看当前kerberos系统中是否存在可以被用户访问的该服务。如果不存在，认证失败结束，。如果存在，继续接下来的认证。
② TGS使用自己的密钥将TGT中的内容进行解密，此时他看到了经过AS认证过后并记录的用户信息，一把Session_KEY即CT_SK，还有时间戳信息，他会现根据时间戳判断此次通信是否真是可靠有无超出时延。
③ 如果时延正常，则TGS会使用CK_SK对客户端的第一部分内容进行解密（使用CT_SK加密的客户端信息），取出其中的用户信息和TGT中的用户信息进行比对，如果全部相同则认为客户端身份正确，方可继续进行下一步。
④ 此时KDC将返回响应给客户端，响应内容包括：

第一部分：用于客户端访问网络服务的使用Server密码加密的ST（Servre Ticket），其中包括客户端的Name，IP，需要访问的网络服务的地址Server IP，ST的有效时间，时间戳以及用于客户端和服务端之间通信的CS_SK（Session Key）。
第二部分：使用CT_SK加密的内容，其中包括CS_SK和时间戳，还有ST的有效时间。由于在第一次通信的过程中，AS已将CT_SK通过客户端密码加密交给了客户端，且客户端解密并缓存了CT_SK，所以该部分内容在客户端接收到时是可以自己解密的。

至此，第二次通信完成。

第三次通信

此时的客户端收到了来自KDC（TGS）的响应，并使用缓存在本地的CT_SK解密了第二部分内容（第一部分内容中的ST是由Server密码加密的，客户端无法解密），检查时间戳无误后取出其中的CS_SK准备向服务端发起最后的请求。

客户端：
① 客户端使用CK_SK将自己的主机信息和时间戳进行加密作为交给服务端的第一部分内容，然后将ST（服务授予票据）作为第二部分内容都发送给服务端。
服务端：
② 服务器此时收到了来自客户端的请求，他会使用自己的密钥，即Server密钥将客户端第二部分内容进行解密，核对时间戳之后将其中的CS_SK取出，使用CS_SK将客户端发来的第一部分内容进行解密，从而获得经过TGS认证过后的客户端信息，此时他将这部分信息和客户端第二部分内容带来的自己的信息进行比对，最终确认该客户端就是经过了KDC认证的具有真实身份的客户端，是他可以提供服务的客户端。此时服务端返回一段使用CT_SK加密的表示接收请求的响应给客户端，在客户端收到请求之后，使用缓存在本地的CS_ST解密之后也确定了服务端的身份（其实服务端在通信的过程中还会使用数字证书证明自己身份）。

至此，第三次通信完成。此时也代表着整个kerberos认证的完成，通信的双方都确认了对方的身份，此时便可以放心的进行整个网络通信了。

整个kerberos认证的过程较为复杂，三次通信中都使用了密钥，且密钥的种类一直在变化，并且为了防止网络拦截密钥，这些密钥都是临时生成的Session Key，即他们只在一次Session会话中起作用，即使密钥被劫持，等到密钥被破解可能这次会话都早已结束。

2 Kerberos配置介绍

Kerberos最重要的配置文件是/etc/krb5.conf文件，下面将详细解释该文件的组成部分，以及每个参数的解释。

[logging]:

作用:

　　用于指定kerberos守护进程的日志记录方式，换句话说，就是指定server端的日志打印位置。

常用标签:

　　default:

　　　　指定默认的存储路径，默认值:"FILE:/var/log/krb5libs"。

　　kdc:

　　　　指定KDC日志的存储路径，默认值:"FILE:/var/log/krb5kdc.log"。

　　admin_server:

　　　　指定管理员服务器的日志，默认值:"FILE:/var/log/kadmind.log"。

[libdefaults]:

作用:

　　用于指定kerberos使用的默认配置。

　　例如:当进行身份验证而未指定Kerberos域时，则使用default_realm参数来指定的Kerberos域。

常用标签:

　　default_realm:

　　　　标识客户端的默认Kerberos领域。将其值设置为您的Kerberos领域。如果未设置此值，则在调用诸如"kinit"之类的程序时，必须为每个Kerberos主体指定一个领域。

　　dns_lookup_realm:

　　　　此模块查找DNS记录，以用于备用主机到领域的映射以及默认领域。仅当dns_lookup_realm变量设置为"true"时，它才起作用。默认值为"false"。

　　dns_lookup_kdc:

　　　　指示是否应使用DNS SRV记录来定位领域的KDC和其他服务器（如果未在领域的krb5.conf信息中列出它们）。默认值为"false"。

　　ticket_lifetime:

　　　　设置初始票证请求的默认生存期。默认值为1天(即24h)

　　renew_lifetime:

　　　　设置初始票证请求的默认可更新生命周期。默认值为0。我这里设置的是"7d"。内部一般将renew_lifetime属性的值设置为7天。这允许Hadoop组件(如hive、hdfs、yarn等)更新其Kerberos票据。一旦发放票据，可以在7天内续订。

　　forwardable：

　　　　如果此标志为true，则表示初始票证将是可转发的(这意味着如果具有TGT的用户登录到远程系统，则KDC可以颁发新的TGT，而不需要用户再次进行身份验证)。默认值为false。

[kdc]:

作用:

　　指定kdc.conf文件的位置。

[realms]

作用:

　　文件的[realms]部分中的每个标记都是Kerberos领域的名称。

常用标签:

　　kdc:

　　　　在该领域中运行KDC的主机的名称或地址。可以包括一个可选的端口号，以冒号与主机名分隔。如果名称或地址包含冒号（例如，如果它是IPv6地址），则将其括在方括号中，以将冒号与端口分隔符区分开。

　　　　可以为KDC指定一个端口，如果没有配置，则KDC使用默认端口88。

　　admin_server:

　　　　标识运行管理服务器的主机。通常，这是主Kerberos服务器。必须为此标签赋予一个值，以便与该领域的kadmind服务器通信。

　　　　可以为admin_server指定一个端口，如果没有配置，则使用默认端口749。

[domain_realm]:

作用:

　　提供了从域名或主机名到Kerberos领域名称的转换(指定DNS域名和Kerberos域名之间的映映射关系。指定服务器的FQDN，对应的domain_realm值决定了主机所属的域)。

　　标签名称可以是主机名或域名，其中域名以句点（.）表示。该关系的值是该特定主机或域的Kerberos领域名称。除非提供明确的域名关系，否则主机名关系将隐式提供相应的域名关系。可以在领域部分中或使用DNS SRV记录来标识Kerberos领域。主机名和域名应小写。

3 Kerberos手动部署过程

在EasyOps中将Kerberos的安装步骤利用Ansible做成了脚本化，如果需要手动部署，安装如下步骤可以实现

3.1 安装服务包

需要安装两个主要的组件：Kerberos KDC和Kerberos客户端。在Debian或Ubuntu上，你可以使用apt-get来安装。在CentOS或者RHEL上，你可以使用yum。yum安装命令如下：

sudo yum -y install krb5-client krb5-server krb5-workstation

3.2 配置Kerberos KDC

配置KDC需要修改两个主要的配置文件：/etc/krb5.conf和/var/kerberos/krb5kdc/kdc.conf。这两个文件定义了你的Kerberos领域和KDC的相关配置。

3.3 初始化Kerberos数据库

使用kdb5_util工具创建新的Kerberos数据库，并设定Kerberos领域的master密钥：

sudo kdb5_util create -r EXAMPLE.COM -s

3.4 创建管理员用户

你需要创建一个Kerberos管理员用户，这个用户可以管理Kerberos数据库。使用kadmin.local创建新的管理员用户：

sudo kadmin.local -q "addprinc admin/admin"

3.5 启动KDC和admin服务

启动Kerberos KDC和admin服务，你可以使用以下的命令：

sudo systemctl start krb5kdc.service
sudo systemctl start kadmin.service

3.6 配置Kerberos客户端

在Kerberos客户端，你需要配置/etc/krb5.conf，设定默认的领域和KDC，这和在KDC上的设置类似。然后你可以使用kinit和klist等命令来测试Kerberos的设置。

当然如果要实现高可用，还涉及从节点的部署、主从的同步等等，这里不展开叙述。

4 常见问题排查

Bad lifetime value

Cause: 提供的生命周期值无效或格式不正确。

解决方法: 确保提供的值与 kinit(1) 手册页中的“时间格式”一节相符。

Bad start time value

Cause: 提供的开始时间值无效或格式不正确。

解决方法: 确保提供的值与 kinit(1) 手册页中的“时间格式”一节相符。

Cannot contact any KDC for requested realm

Cause: 请求的领域中没有 KDC 响应。

解决方法: 确保至少可以访问一个 KDC（主从皆可），或 krb5kdc 守护进程正在 KDC 上运行。有关已配置的 KDC (kdc = kdc-name) 的列表，请查看 /etc/krb5/krb5.conf 文件。

Cannot determine realm for host: host is 'hostname'

Cause: Kerberos 无法确定主机的领域名称。

解决方法: 确保存在缺省领域名称，或在 Kerberos 配置文件 (krb5.conf) 中设置了域名映射。

Cannot find a kadmin KDC entry in krb5.conf(4) or DNS Service Location records for realm 'realmname'

Cannot find a kpassword KDC entry in krb5.conf(4) or DNS Service Location records for realm 'realmname'

Cannot find a master KDC entry in krb5.conf(4) or DNS Service Location records for realm 'realmname'

Cannot find any KDC entries in krb5.conf(4) or DNS Service Location records for realm 'realmname'

Cause: krb5.conf 文件或 DNS 服务器记录配置不正确。

解决方法: 确保 Kerberos 配置文件 (/etc/krb5/krb5.conf) 或 KDC 的 DNS 服务器记录已配置正确。

Cannot find address for 'hostname': 'error-string'

Cause: 在 DNS 记录中找不到给定主机名的地址。

解决方法: 修复 DNS 中的主机记录，或更正 DNS 查找进程中的错误。

cannot initialize realm realm-name

Cause: KDC 可能没有存储文件。

解决方法: 确保 KDC 具有存储文件。否则，请使用 kdb5_util 命令创建一个存储文件，然后尝试重新启动 krb5kdc 命令。

Cannot resolve KDC for requested realm

Cause: Kerberos 无法确定领域的任何 KDC。

解决方法: 确保 Kerberos 配置文件 (krb5.conf) 在 realm 部分指定了 KDC。

Cannot resolve network address for KDCs 'hostname' discovered via DNS Service Location records for realm 'realm-name'

Cannot resolve network address for KDCs 'hostname' specified in krb5.conf(4) for realm 'realm-name'

Cause: krb5.conf 文件或 DNS 服务器记录配置不正确。

解决方法: 确保 Kerberos 配置文件 (/etc/krb5/krb5.conf) 或 KDC 的 DNS 服务器记录已正确配置。

Can't open/find Kerberos configuration file

Cause: Kerberos 配置文件 (krb5.conf) 不可用。

解决方法: 确保 krb5.conf 文件位于正确的位置，并具有合适的权限。该文件应可由 root 写入，并可由其他任何用户读取。

Client 'principal' pre-authentication failed

Cause: 对主体的验证失败。

解决方法: 确保用户使用的是正确的口令。

Client or server has a null key

Cause: 主体拥有空密钥。

解决方法: 使用 kadmin 的 cpw 命令修改主体，使其拥有非空密钥。

Communication failure with server while initializing kadmin interface

Cause: 为主 KDC 指定的主机未运行 kadmind 守护进程。

解决方法: 确保为主 KDC 指定了正确的主机名。如果指定了正确的主机名，请确保 kadmind 正在指定的主 KDC 上运行。

Credentials cache file permissions incorrect

Cause: 您对凭证高速缓存 (/tmp/krb5cc_uid) 没有相应的读写权限。

解决方法: 请确保您拥有对凭证高速缓存的读写权限。

Credentials cache I/O operation failed XXX

Cause: Kerberos 在向系统的凭证高速缓存 (/tmp/krb5cc_uid) 进行写入时出现问题。

解决方法: 请使用 df 命令确认尚未删除凭证高速缓存，并且设备中还有剩余空间。

Decrypt integrity check failed

Cause: 您的票证可能无效。

解决方法: 验证以下两种情况：

确保您的凭证有效。使用 kdestroy 销毁票证，然后使用 kinit 创建新的票证。

确保目标主机的密钥表文件的服务密钥版本正确。使用 kadmin 查看 Kerberos 数据库中服务主体（例如 host/FQDN-hostname）的密钥版本号。另外，在目标主机上使用 klist -k 命令，以确保该主机具有相同的密钥版本号。

Decrypt integrity check failed for client 'principal' and server 'hostname'

Cause: 您的票证可能无效。

解决方法: 确保您的凭证有效。使用 kdestroy 命令销毁票证，然后使用 kinit 命令创建新票证。

failed to obtain credentials cache

Cause: 在 kadmin 初始化期间，kadmin 尝试获取 admin 主体的凭证时失败。

解决方法: 确保在执行 kadmin 命令时使用正确的主体和口令。

Field is too long for this implementation

Cause: 基于 Kerberos 的应用程序所发送的消息太长。如果传输协议是 UDP，则可能会生成此错误。UDP 的缺省最大消息长度是 65535 字节。此外，对通过 Kerberos 服务发送的协议消息中的单个字段也有限制。

解决方法: 确认您没有在 KDC 服务器的 /etc/krb5/kdc.conf 文件中将传输协议限制为 UDP。

GSS-API (or Kerberos) error

Cause: 此消息是通用的 GSS-API 或 Kerberos 错误消息，可能由几种不同的问题所导致。

解决方法: 检查 /var/krb5/kdc.log 文件，找出发生此错误时记录的更具体的错误消息。

Improper format of Kerberos configuration file

Cause: Kerberos 配置文件包含无效项。

解决方法: 确保 krb5.conf 文件中的所有关系后面都跟有 "=" 符号和值。另外，请确认每个子段中的括号都是成对出现的。

Invalid credential was supplied

Service key not available

Cause: 凭证高速缓存中的服务票证可能不正确。

解决方法: 尝试使用该服务之前，请销毁当前凭证高速缓存并重新运行 kinit 命令。

Invalid flag for file lock mode

Cause: 出现 Kerberos 内部错误。

解决方法: 请报告错误。

Invalid message type specified for encoding

Cause: Kerberos 无法识别基于 Kerberos 的应用程序发送的消息类型。

解决方法: 如果使用的基于 Kerberos 的应用程序是由您的站点或供应商开发的，请确保此应用程序正确使用 Kerberos。

kadmin: Bad encryption type while changing host/FQDN's key

Cause: 在较新的发行版中，基本版本中包括更多的缺省加密类型。客户机请求的加密类型可能不受运行该软件旧版本的 KDC 支持。

解决方法: 在客户机上的 krb5.conf 中设置 permitted_enctypes，使其不包括 aes256 加密类型。将需要对每台新的客户机执行此步骤。

KDC can't fulfill requested option

Cause: KDC 不允许请求的选项。一种可能是正在请求以后生效或可转发的选项，而 KDC 不允许这些选项。另一种可能是请求了 TGT 更新，但没有可更新的 TGT。

解决方法: 确定是请求了 KDC 不允许的选项，还是票证类型不可用。

KDC reply did not match expectation: KDC not found. Probably got an unexpected realm referral

Cause: KDC 回复中未包含所需的主体名称，或者响应中的其他值不正确。

解决方法: 确保您与之通信的 KDC 符合 RFC4120，发送的请求是 Kerberos V5 请求，并且该 KDC 可用。

kdestroy: Could not obtain principal name from cache

Cause: 凭证高速缓存缺失或已损坏。

解决方法: 检查提供的高速缓存位置是否正确。如有必要，使用 kinit 删除 TGT 并获取新的 TGT。

kdestroy: No credentials cache file found while destroying cache

Cause: 凭证高速缓存 (/tmp/krb5c_uid) 缺失或已损坏。

解决方法: 检查提供的高速缓存位置是否正确。如有必要，使用 kinit 删除 TGT 并获取新的 TGT。

kdestroy: TGT expire warning NOT deleted

Cause: 凭证高速缓存缺失或已损坏。

解决方法: 检查提供的高速缓存位置是否正确。如有必要，使用 kinit 删除 TGT 并获取新的 TGT。

Kerberos authentication failed

Cause: Kerberos 口令错误，或该口令可能与 UNIX 口令不同步。

解决方法: 如果口令不同步，则必须指定 Kerberos 口令以完成验证。用户可能会忘记其原始口令。

Key version number is not available for principal principal

Cause: 密钥的密钥版本与应用服务器中的密钥版本不匹配。

解决方法: 使用 klist -k 命令检查应用服务器上的密钥版本。

Key version number for principal in key table is incorrect

Cause: 密钥表文件中主体的密钥版本与 Kerberos 数据库中的版本不同。可能已更改了服务密钥，也可能正在使用旧服务票证。

解决方法: 如果更改了服务密钥（例如，通过使用 kadmin），则需要提取新密钥，并将其存储在正在运行该服务的主机的密钥表文件中。或者，您也可能正在使用具有较旧密钥的旧服务票证。在这种情况下，可能需要运行 kdestroy 命令，然后再次运行 kinit 命令。

kinit: gethostname failed

Cause: 本地网络配置中的错误导致 kinit 失败。

解决方法: 确保主机配置正确。

Cause: Kerberos PAM 模块缺失，或不是有效的可执行二进制文件。

解决方法: 确保 Kerberos PAM 模块在 /usr/lib/security 目录下，并且是有效的可执行二进制文件。另请确保 login 的 PAM 配置文件包含指向 pam_krb5.so.1 的正确路径。

Looping detected getting initial creds: 'client-principal' requesting ticket 'service-principal'. Max loops is value. Make sure a KDC is available.

Cause: Kerberos 多次尝试获取初始票证，但均失败。

解决方法: 确保至少有一个 KDC 正在响应验证请求。

Master key does not match database

Cause: 装入的数据库转储不是基于包含主密钥的数据库创建的。主密钥位于 /var/krb5/.k5.REALM 中。

解决方法: 确保装入的数据库转储中的主密钥与 /var/krb5/.k5.REALM 中的主密钥匹配。

Matching credential not found

Cause: 未找到与请求匹配的凭证。凭证高速缓存中没有您的请求需要的凭证。

解决方法: 使用 kdestroy 销毁票证，然后使用 kinit 创建新的票证。

Message out of order

Cause: 使用顺序保密机制发送的消息送达时顺序错误。某些消息可能已在传输过程中丢失。

解决方法: 必须重新初始化 Kerberos 会话。

Message stream modified

Cause: 计算出的校验和与消息校验和不匹配。消息在传输过程中可能已被修改，这表明存在安全漏洞。

解决方法: 确保消息在网络中正确发送。由于此消息还可能表明消息在发送过程中被篡改，因此请销毁票证，然后重新初始化正在使用的 Kerberos 服务。

No credentials cache file found

Cause: Kerberos 找不到凭证高速缓存 (/tmp/krb5cc_uid)。

解决方法: 确保凭证文件存在且可读。否则，请再次尝试运行 kinit 命令。

No credentials were supplied, or the credentials were unavailable or inaccessible

No credential cache found

Cause: 用户的凭证高速缓存不正确或不存在。

解决方法: 用户必须在尝试启动服务之前运行 kinit。

No credentials were supplied, or the credentials were unavailable or inaccessible

No principal in keytab ('filename') matches desired name principal

Cause: 尝试验证服务器时发生错误。

解决方法: 确保 host 主体或服务主体位于服务器的密钥表文件中。

Operation requires "privilege" privilege

Cause: 未在 kadm5.acl 文件中为所使用的 admin 主体分配相应特权。

解决方法: 使用具有相应特权的主体。或者，也可以为所使用的主体配置相应特权。通常，名称中包含 /admin 的主体都具有相应的特权。

PAM-KRB5 (auth): krb5_verify_init_creds failed: Key table entry not found

Cause: 远程应用程序尝试在本地 /etc/krb5/krb5.keytab 文件中读取主机的服务主体，但不存在任何主体。

解决方法: 将主机的服务主体添加到主机的密钥表文件中。

Permission denied in replay cache code

Cause: 无法打开系统的重放高速缓存。首次运行服务器时所使用的用户 ID 可能与当前的用户 ID 不同。

解决方法: 确保重放高速缓存具有相应的权限。重放高速缓存存储在运行基于 Kerberos 的服务器应用程序的主机上。对于非 root 用户，重放高速缓存文件名为 /var/krb5/rcache/rc_service_name_uid。对于 root 用户，重放高速缓存文件名为 /var/krb5/rcache/root/rc_service_name。

Protocol version mismatch

Cause: 很可能向 KDC 发送了 Kerberos V4 请求。Kerberos 服务仅支持 Kerberos V5 协议。

解决方法: 确保应用程序使用的是 Kerberos V5 协议。

Request is a replay

Cause: 请求已经发送到该服务器，并进行了处理。票证可能已被盗用，其他用户正在尝试重用这些票证。

解决方法: 等待几分钟，然后重新发送请求。

Requested principal and ticket don't match: Requested principal is 'service-principal' and TGT principal is 'TGT-principal'

Cause: 您正连接的服务主体和您拥有的服务票证不匹配。

解决方法: 确保 DNS 正常运行。如果使用的是其他供应商的软件，请确保该软件使用的主体名称正确。

Server refused to negotiate authentication, which is required for encryption. Good bye.

Cause: 远程应用程序无法接受或已配置为不接受来自客户机的 Kerberos 验证。

解决方法: 提供可以协商验证的远程应用程序，或配置该应用程序以使用相应标志来启用验证。