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