Kerberos -超级安全的强认证协议

Kerberos 是一种超级超级安全的强认证协议 在不安全的环境里也能达到安全的效果.
基于Kerberos 能做到帐号集中管理 分级授权方便 也可以做到SSO 单点登录 支持漫游
同时也对机器时间 主机名 DNS等做到了规范
国外很多大学机构都用她, Windows认证也是用的Kerberos

2008年和 Kerberos 开始亲密接触 更早只有简单了解 没太在意.
2009年开始推广使用至今已3年 非常伟大的设计 超级安全 不怕监听 双向认证.
Kerberos MIT 实现的官方站点
http://web.mit.edu/Kerberos/
认证过程3次交互简单描述：
Client 向KDC 申请TGT：KDC 生成Session-Key(SKDC-Client)，用Client的密钥(密码的salt hash)加密SKDC-Client，然后和TGT一块发给Client (KDC也可要求Client先证明自己)
Client 向KDC 获取某Server的 Ticket：TGT原样给 KDC，把用SKDC-Client加密的自己的信息和要访问Server的信息 发给 KDC，KDC检查无误后发 Ticket
Client 向 Server 出示Ticket 证明自己(也可要求Server证明自己)

 http://k5wiki.kerberos.org/wiki/Main_Page
--------------------------------------------------------

Kerberos 帐号修改密码的方法

0. 首先保证本机时间 DNS设置 hosts文件 %windir%\krb5.ini 或 /etc/krb5.conf 等是正确的 密码过期也可以修改
1. 命令行方式 kpasswd
执行 kpasswd your.username 或  kpasswd
根据提示先输入原密码 再输入两次新密码
如果有错误 会提示出来 比如密码不匹配 密码不符合要求 或其他错误(见4 报错与解决)
2. 图形界面方式 netidmgr
netidmgr图形界面的Credential - Change Password修改

...
3. 被动用kinit时修改
密码到期时kinit和netidmgr申请票据时也可以修改
但如果用的 Mac OS X 请直接用 kpasswd 修改密码
4. 报错与解决
Server error: Failed decrypting request
如果在虚拟机里修改密码 请确保不是NAT模式 就是要保证和KDC直连互通
这是防止中间人的安全措施
如果有java相关的报错 请修改系统的 PATH 环境变量 把 java 那个挪到最后

--------------------------------------------------

putty 用 Kerberos 认证的方法 (官方从0.61版本开始支持)

首先 一定要去官方网站下载 putty (一定不要用所谓中文版 前一段报道有后门)
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
官方从0.61版本开始支持 现在版本是 0.62 (之前是有几个美国大学等第三方版本支持)
在选项相应地方启用即可
Connection - SSH - Auth - GSSAPI
确保勾上 Attempt GSSAPI authentication 那个复选框
如果用官方版本 直接用默认的 MIT 优先就行
如果用我们自己精简的极客版 需要改下 第一个选用 User-specific GSSAPI DLL 并填上 C:\windows\gssapi32.dll 如下图
(小技巧： 修改后 存为 Default Settings   Session 以后就不用改了)

这是因为 putty 支持 Kerberos 的代码写死了路径(读注册表先找安装目录 然后该目录下bin下) 囧


 

 ---------------------------------

KDC - Key Distribution Center - A machine that issues Kerberos tickets - a trusted third party - consists of two theoretically independent roles: an Authentication Server (AS) and a Ticket Granting Server (TGS) 

-----------------------------

 Kerberos认证要点: 密码不在网络传输 加密用的密钥是临时生成的 被监听重发无效 时间偏差超过一定时间无效 可以双向认证

http://en.wikipedia.org/wiki/Kerberos_(protocol)#User_Client-based_Logon

User Client-based Logon
    A user enters a username and password on the client machine.
    The client performs a one-way function (hash usually) on the entered password, and this becomes the secret key of the client/user.

Client Authentication

    The client sends a cleartext message of the user ID to the AS requesting services on behalf of the user. (Note: Neither the secret key nor the password is sent to the AS.) The AS generates the secret key by hashing the password of the user found at the database (e.g. Active Directory in Windows Server).
    The AS checks to see if the client is in its database. If it is, the AS sends back the following two messages to the client:
        Message A: Client/TGS Session Key encrypted using the secret key of the client/user.
        Message B: Ticket-Granting-Ticket (which includes the client ID, client network address, ticket validity period, and the client/TGS session key) encrypted using the secret key of the TGS.
    Once the client receives messages A and B, it attempts to decrypt message A with the secret key generated from the password entered by the user. If the user entered password does not match the password in the AS database, the client's secret key will be different and thus unable to decrypt message A. With a valid password and secret key the client decrypts message A to obtain the Client/TGS Session Key. This session key is used for further communications with the TGS. (Note: The client cannot decrypt Message B, as it is encrypted using TGS's secret key.) At this point, the client has enough information to authenticate itself to the TGS.


Client Service Authorization

    When requesting services, the client sends the following two messages to the TGS:
        Message C: Composed of the TGT from message B and the ID of the requested service.
        Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the Client/TGS Session Key.
    Upon receiving messages C and D, the TGS retrieves message B out of message C. It decrypts message B using the TGS secret key. This gives it the "client/TGS session key". Using this key, the TGS decrypts message D (Authenticator) and sends the following two messages to the client:
        Message E: Client-to-server ticket (which includes the client ID, client network address, validity period and Client/Server Session Key) encrypted using the service's secret key.
        Message F: Client/Server Session Key encrypted with the Client/TGS Session Key.


Client Service Request

    Upon receiving messages E and F from TGS, the client has enough information to authenticate itself to the SS. The client connects to the SS and sends the following two messages:
        Message E from the previous step (the client-to-server ticket, encrypted using service's secret key).
        Message G: a new Authenticator, which includes the client ID, timestamp and is encrypted using Client/Server Session Key.
    The SS decrypts the ticket using its own secret key to retrieve the Client/Server Session Key. Using the sessions key, SS decrypts the Authenticator and sends the following message to the client to confirm its true identity and willingness to serve the client:
        Message H: the timestamp found in client's Authenticator plus 1, encrypted using the Client/Server Session Key.
    The client decrypts the confirmation using the Client/Server Session Key and checks whether the timestamp is correctly updated. If so, then the client can trust the server and can start issuing service requests to the server.
    The server provides the requested services to the client.