用於數據嗅探的 Kerberos SSH 中間人
Kerberos 顯然可以防止攻擊者在 SSH 中間人場景中獲取使用者的憑據（攻擊者讓使用者信任其伺服器的公鑰並通過該伺服器重定向流量）。但是，如果攻擊者可以不獲取使用者的憑據，因為他們將能夠在身份驗證後偵聽會話並可能獲取有價值的資訊，包括隨後輸入的憑據，該怎麼辦。
為了清楚起見，這裡是場景：
- 為 Kerberos 設置了 SSH 伺服器 (Server1) 和客戶端 (User1)。Server1 具有用於身份驗證等的標準公鑰/私鑰對。
- User1 最初嘗試連接到 Server1，但他們的連接被攻擊者重定向到 Server2。
- 使用者 1 沒有仔細查看來自 Server2 的公鑰，並接受它作為 Server1 的已知主機密鑰（因此設置了 MITM）。
- User1 通過 Server1 通過 Server2 進行 Kerberos 身份驗證（Server2 設置兩個單獨的 SSH 會話並在它們之間傳遞資訊）。由於 Kerberos 的工作方式，攻擊者在身份驗證期間不會獲得任何有價值的資訊。
- 但是，一旦通過身份驗證，User1 就會開始在 Server1 上執行操作，包括 sudo。攻擊者在通過 Server2 時能夠看到會話的所有內容。
這行得通嗎？在身份驗證步驟中使用公鑰身份驗證顯然會阻止這種情況。但是 Kerberos 或 SSH 協議中有什麼東西可以防止這種情況發生嗎？
從評論中的討論有所擴展：
您的問題是：如果您將 SSH 流量從客戶端轉移到流氓 SSH 伺服器，是否可以通過流氓 SSH 伺服器擷取客戶端 Kerberos 票證並將其轉發到真正的 Server1 來進行重放攻擊？
這依賴於防止中間人攻擊失敗的 SSH 安全機制，即客戶端尚未記憶體來自 Server1 的真實伺服器密鑰，或者如果有，
StrictHostKeyChecking則已被禁用或忽略。由於 SSH + Kerberos GSS-API 依賴 SSH 進行數據加密，因此您的假設是，如果對 Server1 的身份驗證成功，中間人流氓 SSH 伺服器可以訪問所有傳輸的資訊，因為 SSH 不使用 Kerberos基於 SSH 加密之上的數據加密。
是的，這在理論上可行，但前提是您的流氓 SSH 伺服器 Server2 成功地將客戶端模擬到 Server1。
我認為真正的 Server1 會拒絕（或至少應該）拒絕轉發的憑據。作為 Kerberos 身份驗證的一部分，客戶端發送兩條消息，即Service 票證和 Authenticator。儘管轉發的服務票證有效，但隨附的身份驗證器則無效。
SSH 使用的RFC 4121 Kerberos GSS-API 規範將通道綁定資訊作為身份驗證消息的一部分：
“通道綁定標籤旨在用於辨識 GSS-API 安全上下文建立令牌所針對的特定通信通道，從而限制了攻擊者可以重用攔截的上下文建立令牌的範圍。”
即 Authenticator 消息包括發送者的 ip-address 和源埠，以及目標 ip-address 和埠號。如果這些與實際連接的不匹配，則 Kerberos 交換應被 Server1 拒絕。