Linux ksu（kerberized 超級使用者）命令無法使用記憶體的服務（主機）票證
問題在最後
關於我的環境
我在兩種不同的環境中嘗試過：（i）在 Active Directory（Microsoft）域中註冊的 Linux Ubuntu 16.04LTS 伺服器和（ii）在 FreeIPA 領域中註冊的 Linux Ubuntu 16.04LTS 伺服器。
Krb5 二進製版本：
$ strings libkrb5.so | grep BRAND KRB5_BRAND: krb5-1.13.2-final 1.13.2 2015050我喜歡做什麼
我正在嘗試使用ksu命令以另一個使用者身份登錄目前主機（authdemo4.addemo.it ）： kservice。具體來說，我正在嘗試（i）為主機authdemo4.addemo.it獲取使用者**kservice的服務票證，（ii）將票證保存在 MIT 記憶體文件*/media/public/krb_kservice和（iii）提供ksu命令的這張票，以便以kservice*身份登錄。
它應該是可能的
ksu MIT 文件指出，可以使用記憶體文件中的服務票證，讓我們引用*：*
否則，ksu 會在源記憶體中查找適當的 Kerberos 票證。票證可以是用於終端伺服器的票證，也可以是用於目標主體領域的票證授予票證 (TGT)。如果終端伺服器的票證已經在記憶體中，它會被解密和驗證。如果它不在記憶體中但 TGT 在，則 TGT 用於獲取端伺服器的票證。然後驗證終端伺服器票證。
我的實驗和結果
當使用 TGT Kerberos 票時.. 它就像一個魅力：
$ kinit -c /media/public/krb_kservice kservice Password for kservice@ADDEMO.IT: $ ksu kservice -n kservice@ADDEMO.IT -c FILE:/media/public/krb_kservice Authenticated kservice@ADDEMO.IT Account kservice: authorization for kservice@ADDEMO.IT successful Changing uid to kservice (50006) groups: cannot find name for group ID 50024 kservice@authdemo4:/home/userlab$這是記憶體內容，只有 TGT：
$ klist -c /media/public/krb_kservice Ticket cache: FILE:/media/public/krb_kservice Default principal: kservice@ADDEMO.IT Valid starting Expires Service principal 11/08/2017 11:44:07 11/08/2017 21:44:07 krbtgt/ADDEMO.IT@ADDEMO.IT renew until 11/09/2017 11:44:03當嘗試使用終端伺服器 Kerberos 票證（服務票證）失敗時，ksu忽略記憶體的票證並詢問使用者密碼：
$ kinit -S HOST/authdemo4@ADDEMO.IT -c /media/public/krb_kservice kservice Password for kservice@ADDEMO.IT: $ ksu kservice -n kservice@ADDEMO.IT -c FILE:/media/public/krb_kservice WARNING: Your password may be exposed if you enter it here and are logged in remotely using an unsecure (non-encrypted) channel. Kerberos password for kservice@ADDEMO.IT: :請注意，我已經嘗試了所有這些服務主體：host/authdemo4.addemo.it@ADDEMO.IT、HOST/authdemo4.addemo.it@ADDEMO.IT、host/authdemo4@ADDEMO.IT、HOST/authdemo4@ADDEMO.IT
這是記憶體內容，只有服務票：
$ klist -f -c /media/public/krb_kservice Ticket cache: FILE:/media/public/krb_kservice Default principal: kservice@ADDEMO.IT Valid starting Expires Service principal 11/08/2017 13:51:05 11/08/2017 23:51:05 HOST/authdemo4@ADDEMO.IT renew until 11/09/2017 13:51:02, Flags: FPRIA它是 proxiable-forwardable-renewable-initial-preauthenticated 票證。
簡而言之：我對終端伺服器服務票的嘗試不起作用。
我通過 Wireshark 檢查了對 DC 的ksu Kerberos 請求，以找出與我請求的服務票證的差異。服務名稱是相同的“ host/authdemo4 ”，ksu將canonizable標誌添加到票證中，並在**kinit將請求發送到 AS時向TGS 詢問票證:-(
更新，使用 kvno 命令（失敗）
我用 Wireshark 深入檢查了ksu執行的 TGS 請求/響應，我發現正確的服務是：host/authdemo4@ADDEMO.IT
我嘗試使用kvno將服務票證插入記憶體：
插入 TGT：
$ kinit kservice -c ./prova.cc Password for kservice@ADDEMO.IT:插入服務票：
$ kvno host/authdemo4@ADDEMO.IT -c ./prova.cc host/authdemo4@ADDEMO.IT: kvno = 17檢查記憶體內容：
$ klist -c ./prova.cc Ticket cache: FILE:./prova.cc Default principal: kservice@ADDEMO.IT Valid starting Expires Service principal 11/09/2017 15:18:53 11/10/2017 01:18:53 krbtgt/ADDEMO.IT@ADDEMO.IT renew until 11/10/2017 15:18:48 11/09/2017 15:19:07 11/10/2017 01:18:53 host/authdemo4@ADDEMO.IT renew until 11/10/2017 15:18:48呼叫 ksu：
$ ksu kservice -n kservice@ADDEMO.IT -c FILE:./prova.cc Authenticated kservice@ADDEMO.IT Account kservice: authorization for kservice@ADDEMO.IT successful Changing uid to kservice (50006) groups: cannot find name for group ID 50024它似乎有效，但它總是忽略服務票證並從頭開始再次執行對主機 / authdemo4****的 TGS 請求。我還檢查了（使用 Wireshark）ksu和kvno請求的響應之間的差異，->I<- 沒有發現任何差異（見附圖）：
我也嘗試過多次使用ksu而不清除記憶體和每次都會再次執行 TGS 請求。
簡而言之：這種使用終端伺服器服務票證的嘗試不起作用（總是重新請求服務票證）。
問題
它們有點重疊:-)
- 有沒有辦法用與ksu兼容的服務票證填充 Kerberos 記憶體文件？
- 為了向 TGS 執行服務票證請求，是否有kvno命令的替代方法？
- 難道我做錯了什麼？任何提示？
- 你認為這是一個 ksu 錯誤嗎？:-)
問候
答案
有沒有辦法用與 ksu 兼容的服務票證填充 Kerberos 記憶體文件？
不，因為版本 1.13 ksu沒有利用記憶體的服務票證
為了向 TGS 執行服務票證請求，是否有 kvno 命令的替代方法？
我的搜尋並沒有找到替代品，但之前的答案使這對我來說不那麼重要
難道我做錯了什麼？任何提示？
不，看來我工作正常，問題是改變（未記錄）的 ksu行為
你認為這是一個 ksu 錯誤嗎？:-)
ABOUT YES，這是一個 ksu 錯誤或文件錯誤，開發人員更改了行為但忘記與文件同步
我送出了錯誤報告並獲得了回饋（感謝 ksu 維護者 Greg Hudson 的及時支持）。他們聲明之前的錯誤修復從版本 1.13 更改了 ksu 行為，並且他們沒有註意到/沒有更新文件。
送出的錯誤報告： http: //krbdev.mit.edu/rt/Ticket/Display.html ?id=8619
目前的 ksu 行為不符合文件（關於記憶體中的服務票證）。
在 ksu 版本 >= 1.13的情況下，不會從記憶體文件中讀取/驗證端伺服器服務票證，但僅驗證記憶體的 TGT。當呼叫 ksu 時，會執行對 TGS 的服務票證請求，以驗證記憶體的 TGT。
此刻，他們還在思考該怎麼做。我建議恢復記錄的行為，我將在未來用他們的最終決定更新這個問題。更新：他們在錯誤請求中回复並決定恢復記錄的行為，但
ksu在 Krb5 項目中不是高優先級，他們不能保證工作的時間表。