Kerberos+SSH安裝配置使用教程

1、背景說明

最先據說KDC和Kerberos應該是大三的《應用密碼學》，當時感受這套對稱密鑰分發機制比非對稱密鑰的PKI分發機制要好理解。但幾年下來因爲現實中使用SSL的場景比較比（主要是https）接觸得也就比較多因此對PKI的認識反倒超過了KDC。

Kerberos的接觸印象中只有某運營商大數據平臺一主機要ssh到其餘主機時須要先kinit申請票據一把，具體原理不是很清楚，也沒有深刻探究。這幾天一是比較有空二是感受之後用得上因此來探究一番，本文能夠認爲是本連接文檔的一次實現。

另外，首先要明確Kerberos是KDC思想的一個具體實現，正如當下的數字簽名證書是PKI思想的一個具體實現同樣；只是他們都實現得都比較好，以致於與各自的思想基本成爲同義詞。

 

2、Kerberos+SSH安裝配置

2.1 安裝配置Kerberos

2.1.1 前置操做

將當前用戶設置成sudo免密碼。編緝/etc/sudoers文件追加如下內容（ls是我當前用戶，操做時請改爲本身的）：

ls ALL=(ALL) NOPASSWD: ALL

將後續要使用的域名/主機名指向本地。編緝/etc/hosts寫入如下內容（192.168.220.143是我電腦當前的IP，改爲本身的；最後的ls-virtual-machine是我電腦當前的主機名，改爲本身的；另外若是/etc/hosts存在有將主機名解析到127.0.0.1的條目，則應將其刪除）

127.0.0.1 localhost 192.168.220.143 monarch.example.com monarch krb1.example.com krb1 ls-virtual-machine

 

2.1.2 安裝Kerberos服務

sudo apt install krb5-admin-server krb5-kdc -y 

安裝krb5-admin-server時要確認幾個問題（不一樣操做系統用Kerberos形式可能有些許差異，但意思都差很少），以下輸入直接回車便可。

指定默認領域，使用EXAMPLE.COM：

Default Kerberos version 5 realm? EXAMPLE.COM

默認領域使用的Kerberos服務器，使用krb1.example.com（前邊2.1咱們已將krb1.example.com也指向本地）

Kerberos servers for your realm: krb1.example.com

默認領域使用的管理服務器，同樣使用krb1.example.com：

Administrative server for your Kerberos realm: krb1.example.com

 

2.1.3 初始化配置

使用如下命令初始化前邊配置的EXAMPLE.COM領域對應的數據庫，並設置該領域的密碼：

sudo krb5_newrealm

編緝/etc/krb5.conf，定位到[domain_realm]節區，追回如下內容：

.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM

繼續編緝/etc/krb5.conf，在文件末尾追加如下內容，設置其日誌文件目錄：

[logging]
    kdc = FILE:/var/log/kerberos/krb5kdc.log admin_server = FILE:/var/log/kerberos/kadmin.log default = FILE:/var/log/kerberos/krb5lib.log

因爲/var/log/kerberos目錄是不存在的，因此咱們還要把這日誌目錄和文件建立出來：

sudo mkdir /var/log/kerberos sudo touch /var/log/kerberos/{krb5kdc,kadmin,krb5lib}.log sudo chmod -R 750 /var/log/kerberos

最後爲使以上配置生效，咱們須要重啓服務：

sudo invoke-rc.d krb5-admin-server restart sudo invoke-rc.d krb5-kdc restart

 

2.1.4 建立策略集

策略集就是規則的集合，咱們這裏建立admin/host/service/user四個策略集（minlength是策略集的密碼長度，minclasses是密碼的元素種類），過程以下：

ls@ls-virtual-machine:~$ sudo kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local:  add_policy -minlength 8 -minclasses 3 admin
kadmin.local:  add_policy -minlength 8 -minclasses 4 host
kadmin.local:  add_policy -minlength 8 -minclasses 4 service
kadmin.local:  add_policy -minlength 8 -minclasses 2 user
kadmin.local:  
kadmin.local:  quit

 

2.1.5 在規則集下建立具體帳號

其中的user表示隸屬user策略集，ls是用戶名（ls是我當前用戶名，改爲本身的）；設置的密碼必定要記住，由於該帳號要獲取票據時要使用該密碼：

ls@ls-virtual-machine:~$ sudo kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local:  addprinc -policy user ls
Enter password for principal "ls@EXAMPLE.COM": 
Re-enter password for principal "ls@EXAMPLE.COM": 
Principal "ls@EXAMPLE.COM" created.
kadmin.local:  
kadmin.local:  quit

 

2.2 ssh集成Kerberos

通過以上步驟，咱們已經安裝好了Kerberos，如今來演示如何使用kerberos完成ssh認證和登陸。

2.2.1 安裝ssh

sudo apt install openssh-server openssh-client

 

2.2.2 配置ssh支持Kerberos認證

編緝/etc/ssh/sshd_config，啓用如下項（其中最後的「UsePAM yes」通常已啓用）：

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
GSSAPIKeyExchange yes
UsePAM yes

重啓ssh使配置生效：

sudo invoke-rc.d ssh restart

 

2.2.3 建立ssh登陸相關規則

service仍然是咱們前面添加的service策略集；host是telnet/rsh/ssh等服務在kerberos中的統稱，monarch.example.com是規則適用的主機名：

ls@ls-virtual-machine:~$ sudo kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local:  addprinc -policy service -randkey host/monarch.example.com
Principal "host/monarch.example.com@EXAMPLE.COM" created.
kadmin.local:  ktadd -k /etc/krb5.keytab -norandkey host/monarch.example.com
Entry for principal host/monarch.example.com with kvno 1, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/monarch.example.com with kvno 1, encryption type arcfour-hmac added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/monarch.example.com with kvno 1, encryption type des3-cbc-sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/monarch.example.com with kvno 1, encryption type des-cbc-crc added to keytab WRFILE:/etc/krb5.keytab.
kadmin.local:
kadmin.local:  quit

 

2.2.4 獲取用戶票據

ls是我當前的用戶名，改爲本身的；獲取票據的密碼是2.5中建立規則時設的密碼（klist -f用於查看當前存在的票據）：

ls@ls-virtual-machine:~$ kinit ls
Password for ls@EXAMPLE.COM: 
ls@ls-virtual-machine:~$ 
ls@ls-virtual-machine:~$ klist -f
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: ls@EXAMPLE.COM

Valid starting       Expires              Service principal
2019-08-06T15:56:52  2019-08-07T01:56:52  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 2019-08-07T15:54:39, Flags: FPRIA

 

2.2.5 登陸測試

使用使用獲取票據的用戶（ls）及可經過票據登陸的主機（monarch.example.com），以下不須要密碼便可直接登陸：

 

3、原理分析

由於有很多概念本身也不太肯定，理解可能有誤差甚至錯誤，因此在閱讀時須要自行斟酌。

3.1 KDC原理

角色：密鑰分發中心KDC、用戶A、用戶B。KDC保存有與用戶A、用戶B通訊的對稱密鑰，用戶A、用戶B保存有與KDC通訊的對稱密鑰。

指望操做：用戶A想和用戶B進行通訊。

實現過程：用戶A向KDC，使用K_a-kdc加密，發送想與用戶B通訊的請求。

                  KDC接收到請求後，使用K_a-kdc解密，生成K_a-b，並將其使用K_a-kdc加密發送給A、使用K_b-kdc加密發送給B。

                  A和B接收到後，分別使用K_a-kdc和K_b-kdc解密出K_a-b。

                  A使用K_a-b向B發送加密消息。

說明：能夠看到，在此模式中KDC須要存儲與全部用戶通訊的Key，而全部用戶只須要存儲與KDC通訊的Key，用戶與用戶之間的Key是動態生成和分發的。

 

3.2 Kerberos過程

角色：認證服務器AS、票據承認服務器TGS、服務器端DS、客戶端A；前二者至關於KDC，前三者是Kerberos所指的三個服務器。前三者存放有相互通訊所用的對稱密鑰，客戶端A不存聽任何對稱密鑰。

指望操做：客戶端A想和服務器端DS進行通訊。

實現過程：客戶端A向AS，以明文形式，索取訪問TGS的票據。

                  AS收到請求後，驗證A發來的用戶名密碼，若是正確則生成K_a-tgs，並將其使用藉助密碼生成的K_a-as加密發送給A、使用K_as-tgs加密發送給TGS。

                  A收到後根據也根據密碼生成K_a-as解密，TGS也使用K_as-tgs解密。

                  A使用獲得的K_a-tgs，加密，向TGS請求與B進行通訊。

                  TGS接收到請求後，使用K_a-tgs解密，根據其意向，生成K_a-b，並將其分別使用K_a-tgs加密發送給A、使用K_b-tgs加密發送給B。

                  A和B接收到後，分別使用K_a-tgs和K_b-tgs解密出K_a-b。

                  A使用K_a-b向B發送加密消息。

說明：Kerberos將KDC拆分爲AS和TGS兩個服務，這樣的好處是，K_a-tgs是有有效期的再也不像前邊K_a-kdc同樣長期有效，當K_a-tgs過時以後用戶能夠經過輸入密碼獲取新的K_a-tgs。

 

3.3 SSH中的Kerberos過程

角色對應：Kerberos啓了哪些進程/服務尚未分析哪一個是AS哪一個是TGS就先不懂，SSH服務端至關於DS，SSH客戶端至關於客戶端A。

操做對應：2.1.5的建立帳號，就是在AS數據庫中導入帳號信息。

                 2.2.4中kinit ls，就是向AS申請訪問TGS的票據。

                 2.2.5中登陸時，SSH客戶端才向TGS請求訪問SSH服務端。

 

3.4 KDC與PKI的優劣分析

從最終效果上看，KDC和PKI都完成了對稱密鑰的分發，即效果是同樣的。

從前置條件上看，首先KDC在仍意環境中都須要一個專門的服務（器），其次其要存儲的用戶數據（用戶名、密碼或對稱密鑰）會隨用戶的增加而增加，最後因爲用戶和KDC之間使用的是對稱密鑰因此非否性可能會有問題。

總的而言，感受KDC適用於內部網絡服務之間的通訊，PKI適用於外部網絡客戶端與服務器之間的通訊。

 

參考：

http://techpubs.spinlocksolutions.com/dklar/kerberos.html#krb-install