kerberos（具體可參考rfc1510）是一種網路身份驗證的協議（注意它只包括驗證環節，不負責授權），使用者只需輸入一次身份驗證資訊，就可憑藉此驗證獲得的票據授予票據（ticket-granting ticket）訪問多個接入kerberos的服務，即sso（single sign on，單點登入）。
1.基本概念
關於概念的一點補充，博文kerberos 服務的工作原理中對於tgt和ticket給出了巧妙的比喻：tgt類似於護照，ticket則是簽證，而訪問特定的服務則好比出遊某個國家。與護照一樣，tgt可標識你的身份並允許你獲得多個ticket（簽證），每個ticket對應乙個特定的服務，tgt和ticket同樣具有有效期，過期後就需要重新認證。
2.認證過程
kerberos的認證過程可細分為三個階段：初始驗證、獲取服務票據和服務驗證。第一階段主要是客戶端向kdc中的as傳送使用者資訊，以請求tgt，然後到第二階段，客戶端拿著之前獲得的tgt向kdc中的tgs請求訪問某個服務的票據，最後階段拿到票據（ticket）後再到該服務的提供端驗證身份，然後使用建立的加密通道與服務通訊。
2.1 初始驗證
此過程是客戶端向as請求獲取tgt：
客戶端向as傳送自身使用者資訊（如使用者id），該動作通常發生在使用者初次登陸或使用kinit命令時2.2 獲取服務票據as檢查本地資料庫是否存在該使用者，若存在則返回如下兩條資訊：
訊息a：使用使用者金鑰加密的client/tgs會話金鑰，我們稱之為sk1。其中使用者金鑰是通過對該使用者在資料庫中對應的密碼hash生成的
訊息b：使用tgs的金鑰加密的tgt（包含客戶端id、客戶端網路位址、票據有效期和sk1）
當客戶端收到訊息a和b時，它會嘗試用本地的使用者金鑰（由使用者輸入的密碼或kerberos.keytab檔案中的密碼hash生成）對a進行解密，只有當本地使用者金鑰與as中對應該使用者的金鑰匹配時才能解密成功。對a解密成功後，客戶端就能拿到sk1，才能與tgs進行後續的會話，這裡就相當於as對客戶端的一次驗證，只有真正擁有正確使用者金鑰的客戶端才能有機會與as進行後續會話。而對於訊息b，由於它是由tgs的金鑰加密的，故無法對其解密，也看不到其中的內容。
此過程則是客戶端向tgs請求獲取訪問對應服務的票據：
當客戶端要訪問某個服務時，會向tgs傳送如下兩條訊息：2.3 服務驗證訊息c：訊息b的內容（即加密後的tgt）和服務id 訊息d：通過sk1加密的驗證器（authenticator，包括使用者id和時間戳）
tgs收到訊息c和d後，首先檢查kdc資料庫中是否存在所需服務，若存在則用自己的tgs金鑰嘗試對c中的訊息b進行解密，這裡也是客戶端對tgs的反向認證，只有真正擁有正確金鑰的tgs才能對b解密，解密成功後就能拿到其中的sk1，然後再用sk1解密訊息d拿到包含使用者id和時間戳的authenticator，通過比較分別來自c和d的使用者id，如果二者匹配，則向客戶端返回如下兩條訊息：
訊息e：通過sk1加密的client/ss會話金鑰，該會話金鑰是kdc新生成的隨機金鑰，用於將來客戶端（client）與服務端（ss）的通訊加密，我們稱之為sk2
訊息f：使用服務的金鑰加密的client-server票據（ticket，包含使用者id、使用者網路位址、票據有效期和sk2），之所以要用服務的金鑰加密，是因為這個ticket是給服務端看的，但又需要經過客戶端傳給服務端，且不能讓客戶端看到。那麼就會有人問，為什麼kdc不直接把訊息e傳送給服務端呢，這樣豈不省事？問題就在於網路時延，若分開傳送，訊息e和f就不能確保同時到達服務端，考慮乙個極端情況，kdc與服務之前的網路臨時不通了，那麼這段時間服務端就無法收到訊息e，導致驗證失敗，而實際上該客戶端是有訪問許可權的。通過公鑰加密這種方式巧妙地迴避了該問題
客戶端收到訊息後，嘗試用sk1解密訊息e，得到client/ss會話金鑰sk2
此過程是客戶端與服務端相互驗證，並通訊
客戶端向服務端傳送如下兩條訊息：3.前提（環境假設）訊息h：通過sk2加密的新的驗證器（authenticator，包含使用者id和時間戳）
服務端收到訊息後，嘗試用自己的金鑰解密訊息g，這裡實際上也是客戶端對服務端的一次驗證，只有真正擁有正確金鑰的服務端才能正確解密，從而有機會拿到ticket中的sk2，然後再用該sk2解密訊息h，同tgs一樣，對分別來自ticket和authenticator中的使用者id進行驗證，如果匹配成功則返回一條確認訊息：
訊息i：通過sk2加密的新時間戳
客戶端嘗試用sk2解密訊息i，得到新時間戳並驗證其正確性，驗證通過後，客戶端與服務端就達到了相互信任，後續的通訊都採用sk2加密，就好比建立了一條加密通道，二者即可享受服務與被服務的樂趣了
共享金鑰：在協議工作前，客戶端與kdc，kdc與服務端都確保有了各自的共享金鑰。
防dos攻擊：kerberos協議本身並沒有解決dos攻擊（denial of service，拒絕服務）防範問題，通常是由系統管理員和使用者自己去定期探測並解決這樣的攻擊。
保障安全個體自身安全：參與到kerberos協議中的安全個體必須確保其秘鑰的安全性，一旦秘鑰洩露或被攻擊者暴力破解，那麼攻擊者就能隨意地偽裝安全個體，做一些不和諧的事情。
不迴圈利用principal的唯一標識：訪問控制的常用方式是通過訪問控制列表（access control lists，acls）來對特定的安全個體進行授權。如果列表中有條記錄對應的安全個體a早已被刪除，而a的唯一標識卻被後來新加的某個個體b再次利用，那麼b就會繼承之前a對應的許可權，這是不安全的。避免這種風險的做法就是不復用principal的唯一標識。
時鐘同步：參與到協議中的主機必須有個時鐘相互之間進行「鬆散同步」，鬆散度是可配置的。為什麼需要同步各主機的時間呢？實際上從kerberos的認證過程可以看到，任何人都可以向kdc請求任何服務的tgt，那攻擊者就有可能中途截獲正常使用者的請求包，然後離線解密，就能合法地拿到tgt。為了防止這種重放攻擊，票據（ticket）會包含時間戳資訊，即具有一定的有效期，因此如果主機的時鐘與kerberos伺服器的時鐘不同步，則認證會失敗。在實踐中，通常用網路時間協議（network time protocol, ntp）軟體來同步時鐘。
4.侷限性
單點風險：過度依賴於kdc服務，kerberos協議運轉時需要kdc的持續響應，一旦kdc服務掛了，或者kdc資料庫被攻破，那麼kerberos協議將無法運轉
安全個體自身的安全：kerberos協議之所以能執行在非安全網路之上，關鍵假設就是主機自身是安全的，一旦主機上的私鑰洩露，攻擊者將能輕易的偽裝該個體實施攻擊
kinit命令用於獲取和快取principal（當前主體）初始的票據授予票據（tgt），此票據用於kerberos系統進行身份安全驗證，實際上它是mit在版權許可的條件下為kerberos協議所研發的免費實現工具mit kerberos（當前最新版本為krb5-1.15.1）的一部分，相關的配套命令還有klist、kdestory、kpasswd、krb5-config等等，基本用法如下：
kinit [-v][-l lifetime] [-s start_time][-r renewable_life][-p | -p][-f | -f][-a][-a][-c][-e][-v][-r][-k [-t keytab_file]][-c cache_name][-n][-s service_name][-i input_ccache][-t armor_ccache][-x attribute[=value]][principal]
各選項具體含義都不做介紹了，可參考官網，較常用的方式就如前言所示，根據指定的事先生成的kerberos.keytab檔案為指定個體進行驗證。驗證通過後，就可以像平常一樣進行hadoop系列操作。那麼它是如何進行驗證的呢？其中的過程和原理又是怎樣的？下面要介紹的kerberos協議細節將會回答你的疑惑。
hadoop安全機制Kerberos詳細介紹
系統，它避免了將密碼 包括密碼hash 在網上傳輸，而是將密碼作為對稱加密的金鑰，通過能不能解密來驗證使用者的身份 2 kerberos在驗證完使用者身份後會發給使用者ticket，這個ticket包含了使用者的授權，使用者拿著這個ticket去享受各種服務，所以在kerberos管理的範圍內使用者...
從kinit到kerberos安全機制
最近老在專案的shell指令碼中看到kinit這個東西，完整的命令是 kinit k t conf kerberos.keytab sherlocky admin example.com 查閱一番資料後了解到，之所以有這個命令，是由於該shell指令碼接下來會訪問hadoop集群，從上面拉取檔案做一...
Kerberos安全體系簡介
1.kerberos簡介 1.1.功能 乙個安全認證協議 用tickets驗證 避免本地儲存密碼和在網際網路上傳輸密碼 包含乙個可信任的第三方 使用對稱加密 客戶端與伺服器 非kdc 之間能夠相互驗證 kerberos只提供一種功能 在網路上安全的完成使用者的身份驗證。它並不提供授權功能或者審計功能...