写点什么

聊聊 kerberos 的 kinit 命令和 ccache 机制

  • 2022 年 3 月 11 日
  • 本文字数:2047 字

    阅读完需:约 7 分钟

1. 前言

大家好,最近遇到了个 kerberos 相关问题,“客户端节点上执行 kinit -R 命令报错:KDC can't fulfill requested option while renewing credentials”, 在次跟大家分享下问题的解决方式,和背后的相关知识点,主要涉及到 kerberos 的 kinit 命令和 ccache 机制。

2. 问题现象与问题日志

  • 问题现象: 客户端执行命令 kinit -R 报错: “KDC can't fulfill requested option while renewing credentials”

  • 问题日志:查看 KDC 服务端日志/var/log/krb5kdc.log 可知,上述报错对应的请求是 TGS_REQ,细节是 liming@TEST.COM for krbtgt/TEST.COM@TEST.COM,其错误原因是 ticket not renewable, 即 ticket 不可刷新;


3. 问题原因

那么 “ticket not renewable” 的原因又有哪些呢?主要有以下几个:


  • 服务端配置文件 /var/kerberos/krb5kdc/kdc.conf 或 /etc/krb5.conf 中对应的 realms 段中没有配置允许 renew ticket;

  • 服务端生成 krbtgt 这个 principal 时,没有配置参数 maxrenewlife,即没有指定其 ticket 的最大可刷新时长;

  • 服务端生成用户的 principal 时,没有配置参数 maxrenewlife,即没有指定其 ticket 的 最大可刷新时长(如报错日志中的 liming@TEST.COM);

  • 客户端上次成功登陆后,获得的 krbtgt 这个 service principal 的可刷新时间已过期,其过期原因是超过了服务端配置的 maxrenewlife(如报错日志中的 krbtgt/TEST.COM@TEST.COM);

  • 客户端上次成功登陆后,用户 principal 的 ticket 已过期,其过期原因是超过了服务端配置的 ticket_lifetime,该参数一般配置为 24 h(如报错日志中的 liming@TEST.COM);

4. 问题解决方案与操作步骤

通过上述分析,我们知道,为解决问题,需要更改服务端的配置参数 max_renewable_life,需要更改服务端上述两个 principal 的 maxrenewlife,并确保客户端指定 kinit -R 时 krbtgt 并没有过期,才能确保任务执行成功。


  1. 服务端更改或确认配置文件/var/kerberos/krb5kdc/kdc.conf 或 /etc/krb5.conf 中,对应的 realms 段中需要配置参数允许刷新:max_renewable_life

  2. 服务端更过或确认上述两个 principal 的参数 maxrenewlife,示例命令如下:


  • modprinc -maxrenewlife "1 week" +allow_renewable liming@TEST.COM

  • modprinc -maxrenewlife "1 week" +allow_renewable krbtgt/TEST.COM@TEST.COM

  • kadmin.local -q "getprinc krbtgt/TEST.COM@TEST.COM" | grep -i life

  • kadmin.local -q "getprinc liming@TEST.COM" | grep -i life


  1. 上述配置修改或确认完毕后,还需要重新登录以生成新的 ticket,后续的 kinit -R 命令才能成功执行;

  2. 同时可以看到,改动 principal 的参数 maxrenewlife 前,klist 不提示 renew until ...,而改动 principal 的参数 maxrenewlife 后,klist 会提示 renew until ....,即在次日期之前可以使用 kinit -R 刷新 ticket;



5. 背景知识: kinit 命令与 ccache 机制

  • 用户在客户端通过 kinit 成功登录 kerberos 后,会将获得的 ticket-granting ticket 缓存到客户端的 ccache (credentail cache) 文件中;

  • ccache 文件地址是通过配置文件 /etc/krb5.conf 中的参数 default_ccache_name 来配置的,在 linux 操作系统中一般是配置为 FILE:/tmp/krb5cc_%{uid},实际对应文件 /tmp/krb5cc_0 等;

  • "kinit -R" 命令,可以用来刷新 ticket-granting ticket,即 tgt;

  • "kinit -R" 命令,只能在 ticket 没有过期之前,且还在 krbtgt 可刷新时间之前,刷新 ticket;

  • "kinit -R" 成功刷新 ticket 之后, 会更新 ccache (credentail cache) 文件,大家可以通过 ls -al 命令查看 linux 中该文件的 ctime 确认这一点;

  • kinit 登录,对应的是 AS_REQ,需要 KDC 中的 Authentication Server (AS) 校验用户身份,获得的是 krbtgt,对应 kerberos 日志中的:liming@TEST.COM for krbtgt/TEST.COM@TEST.COM;

  • kinit 认证完毕后,后续使用受 kerberos 保护的服务,比如登录 hiveserver2 时,命令格式为:beeline -u "jdbc:hive2://uf30-2:10000/default;principal=hive/_HOST@TEST.COM", 此时在底层是一个 TGS_REQ,对应 kerberos 日志中的:liming@TEST.COM for hive/cdp2@TEST.COM;

  • kinit -R 续期 tgt,对应的是 TGS_REQ, 需要 KDC 中的 Ticket Granting Server (TGS) 的响应,其效果是刷新了 krbtgt,更新了 ccache 文件如 /tmp/krb5cc_0, 对应 kerberos 日志中的:liming@TEST.COM for krbtgt/TEST.COM@TEST.COM




[root@uf30-1 ~]# klistTicket cache: FILE:/tmp/krb5cc_0Default principal: admin/admin@CDH.COMValid starting       Expires              Service principal11/13/2020 13:08:27  11/14/2020 13:08:27  krbtgt/CDH.COM@CDH.COM    renew until 11/20/2020 13:08:27[root@uf30-1 ~]# kinit -R[root@uf30-1 ~]# klistTicket cache: FILE:/tmp/krb5cc_0Default principal: admin/admin@CDH.COMValid starting       Expires              Service principal11/13/2020 19:38:15  11/14/2020 19:38:15  krbtgt/CDH.COM@CDH.COM    renew until 11/20/2020 13:08:27
复制代码


发布于: 刚刚阅读数: 2
用户头像

Keep Striving! 2018.04.25 加入

明哥,十四年 IT经验,六年大数据经验; 做过大数据集群的搭建运维,大数据应用系统的开发优化,也做过大数据平台的技术选型以及架构咨询; 目前聚焦于泛大数据生态,包括数据仓库/数据湖,云计算和人工智能。

评论

发布
暂无评论
聊聊 kerberos 的 kinit 命令和 ccache 机制_数据安全_明哥的IT随笔_InfoQ写作平台