kerberos原理
------------------------------------------------------
第一部分：client获得TGT
1. client发送"I want a TGT to get Tickets"给KDC，KDC要求client这个principal输入密码，验证client身
份，验证通过后，生成一个用于该Client和KDC进行安全通信的Session Key（SKDC-Client）。为了保证该
Session Key仅供该Client和自己使用，KDC使用Client的Master Key和自己的Master Key对生成的Session
Key进行加密，从而获得两个加密的SKDC-Client的Copy。对于后者，随SKDC-Client一起被加密的还包含以后
用于鉴定Client身份的关于Client的一些信息(TGT)。最后KDC将这两份Copy一并发送给Client。这里有一点需要注
意的是：为了免去KDC对于基于不同Client的Session Key进行维护的麻烦，就像Server不会保存Session Key
（SServer-Client）一样，KDC也不会去保存这个Session Key（SKDC-Client），而选择完全靠Client自己提
供的方式。
2. 当Client收到KDC的两个加密数据包之后，先使用自己的Master Key对第一个Copy进行解密，从而获得KDC和
Client的Session Key（SKDC-Client），并把该Session key 和TGT进行缓存。相对于Client的Master Key这个
Long-term Key，SKDC-Client是一个Short-term Key，安全保证得到更好的保障，这也是Kerberos多了这一
步的关键所在。同时需要注意的是SKDC-Client是一个Session Key，他具有自己的生命周期，同时TGT和
Session相互关联，当Session Key过期，TGT也就宣告失效，此后Client不得不重新向KDC申请新的TGT，KDC
将会生成一个不同Session Key和与之关联的TGT。同时，由于Client Log off也导致SKDC-Client的失效，
所以SKDC-Client又被称为Logon Session Key。
第二部分：获取某个server的Ticket
1. Client在获得自己和KDC的Session Key（SKDC-Client）之后，生成自己的Authenticator以及所要访问的
Server名称的并使用SKDC-Client进行加密。随后连同TGT一并发送给KDC。
2. KDC使用自己的Master Key对TGT进行解密，提取Client Info和Session Key（SKDC-Client），然后使用这
个SKDC-Client解密Authenticator获得Client Info，对两个Client Info进行比较进而验证对方的真实身份。
验证成功.
3. 验证成功后，KDC处理server Ticket请求，会生成一个Session Key，为了保证这个Session Key仅仅限于发
送请求的Client和他希望访问的Server知晓，KDC会为这个Session Key生成两个Copy，分别被Client和Server
使用。然后从Account database中提取Client和Server的Master Key分别对这两个Copy进行对称加密。对于后
者，和Session Key一起被加密的还包含关于Client的一些信息。然后这两个copy都发送给client。
4. Client实际上获得了两组信息：一个通过自己Master Key加密的Session Key，另一个被Sever的Master Key加
密的数据包，包含Session Key和关于自己的一些确认信息。
第三部分：server对client的验证
1. 通过第一节，我们说只要通过一个双方知晓的Key就可以对对方进行有效的认证，但是在一个网络的环境中，
这种简单的做法是具有安全漏洞，为此,Client需要提供更多的证明信息，我们把这种证明信息称为Authenticator，
在Kerberos的Authenticator实际上就是关于Client的一些信息和当前时间的一个Timestamp。
2. Client通过自己的Master Key对KDC加密的Session Key进行解密从而获得Session Key，随后创建Authenticator
（Client Info + Timestamp）并用Session Key对其加密。最后连同从KDC获得的、被Server的Master Key加密
过的数据包（Client Info + Session Key）一并发送到Server端。我们把通过Server的Master Key加密过的
数据包称为Session Ticket。
3. 当Server接收到这两组数据后，先使用他自己的Master Key对Session Ticket进行解密，从而获得Session Key。
随后使用该Session Key解密Authenticator，通过比较Authenticator中的Client Info和Session Ticket中的
Client Info从而实现对Client的认证。
使用时间戳意义
-------------------
我们试想这样的现象：Client向Server发送的数据包被某个恶意网络监听者截获，该监听者随后将数据包座位自己
的Credential冒充该Client对Server进行访问，在这种情况下，依然可以很顺利地获得Server的成功认证。为了解
决这个问题，Client在Authenticator中会加入一个当前时间的Timestamp。
在Server对Authenticator中的Client Info和Session Ticket中的Client Info进行比较之前，会先提取Authenticator
中的Timestamp，并同当前的时间进行比较，如果他们之间的偏差超出一个可以接受的时间范围（一般是5mins），
Server会直接拒绝该Client的请求。在这里需要知道的是，Server维护着一个列表，这个列表记录着在这个可接受
的时间范围内所有进行认证的Client和认证的时间。对于时间偏差在这个可接受的范围中的Client，Server会从这
个这个列表中获得最近一个该Client的认证时间，只有当Authenticator中的Timestamp晚于通过一个Client的最近
的认证时间的情况下，Server采用进行后续的认证流程。
Kerberos安装配置
===========================================
服务端安装配置
------------------
1. 安装配置
#yum install krb5-server krb5-libs
两个配置文件：/etc/krb5.conf 和 /var/kerberos/krb5kdc/kdc.conf
#cat /etc/krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = LISHEN.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
default_tkt_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
default_tgs_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
permitted_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
[realms]
LISHEN.COM = {
kdc = server.lishen.com
admin_server = server.lishen.com
}
[domain_realm]
.lishen.com = LISHEN.COM
lishen.com = LISHEN.COM
[kdcdefaults]
kdc_ports = 88
kdc_tcp_ports = 88
[realms]
LISHEN.COM = {
master_key_type = aes256-cts
acl_file = /var/kerberos/krb5kdc/kadm5.acl
dict_file = /usr/share/dict/words
admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
}
2. 初始化数据库
/usr/sbin/kdb5_util create -s
3. 配置KDC数据库访问控制权限
# cat /var/kerberos/krb5kdc/kadm5.acl
*/admin@LISHEN.COM *
4. 创建第一个主体
/usr/sbin/kadmin.local -q "addprinc root/admin"
5. 启动程序
/sbin/service krb5kdc start
/sbin/service kadmin start
客户端安装配置
------------------
1. 客户端安装
yum install krb5-libs krb5-workstation
2. 复制服务器端的/etc/krb5.conf到客户端
3. 测试客户端远程管理KDC数据库
#kadmin root/admin
配置SSH使用kerberos验证登录
------------------------------------
目标：客户端(client.lishen.com)不使用密码登录(server.lishen.com)
1. 配置/etc/hosts文件
client:
# cat /etc/hosts
192.168.178.132 client.lishen.com
192.168.178.130 server.lishen.com
server：
# cat /etc/hosts
192.168.178.132 client.lishen.com
192.168.178.130 server.lishen.com
2. 时间同步
client：ntpdate time.nist.gov
server：ntpdate time.nist.gov
3. 配置server的/etc/ssh/ssh_config
GSSAPIAuthentication yes
重启sshd服务
4. 添加server的主体
#kadmin root/admin
kadmin:addprinc -randkey host/server.lishen.com
5.导出host/server.lishen.com主体的账号密码到keytab文件
kadmin:ktadd -k /etc/krb5.keytab host/server.lishen.com
6. client端创建root主体
kadmin:addprinc -randkey root
7. client获取TGT
#kinit -p root
8. client登录server
#ssh server.lishen.com 如果一切正常，就不用输入密码登录了。
9. 使用其它主体登录到root下
在root的家目录下，创建.k5login 文件，输入允许登录的主体，一个主体一行，如：
zhao/admin@LISHEN.COM
然后kinit -p zhao/admin获得TGT，最后使用ssh登录 ssh server.lishen.com
10. 常见命令
kadmin.local：kdc上本地管理数据库的命令
kadmin：远程管理数据库的命令，通过kadmind来操作
kinit：获得TGT
klist -k ：查看keytab中的信息
klist：查看ticket
帮助：
http://blog.csdn.net/wulantian/article/details/42418231
https://ambari.apache.org/1.2.5/installing-hadoop-using-ambari/content/ambari-kerb-1-1.html
https://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-kerberos.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/Using_Kerberos.html#About_Kerberos