Kerberos 显然可以防止攻击者在 SSH 中间人攻击场景（攻击者让用户信任其服务器的公钥并通过该服务器重定向流量）中获取用户的凭据。但是，如果攻击者不获取用户的凭据，因为他们能够在身份验证后监听会话并可能获取有价值的信息（包括随后输入的凭据），那该怎么办呢？
为了清楚起见，场景如下：
- SSH 服务器 (Server1) 和客户端 (User1) 已针对 Kerberos 进行设置。Server1 具有用于身份验证的标准公钥/私钥对等。
- User1 最初尝试连接到 Server1，但他们的连接被攻击者重定向到 Server2。
- User1 并没有仔细查看 Server2 提供的公钥，而是将其接受为 Server1 的已知主机密钥（从而设置了 MITM）。
- 用户 1 通过服务器 2 与服务器 1 进行 Kerberos 身份验证（服务器 2 设置两个单独的 SSH 会话并在它们之间传递信息）。由于 Kerberos 的工作方式，攻击者在身份验证期间不会获得任何有价值的信息。
- 然而，一旦通过身份验证，User1 便开始在 Server1 上执行操作，包括 sudo。攻击者能够在通过 Server2 时看到会话的所有内容。
这可行吗？在身份验证步骤中使用公钥身份验证显然可以阻止这种情况。但是 Kerberos 或 SSH 协议中是否有可以阻止这种情况的机制？
答案1
从评论中的讨论中稍微扩展一下：
您的问题是：如果您将 SSH 流量从客户端转移到恶意 SSH 服务器，那么是否可以通过恶意 SSH 服务器捕获客户端 Kerberos 票证并将其转发到真正的 Server1 来进行重放攻击？
这依赖于防止 MiTM 攻击失败的 SSH 安全机制，即客户端尚未从 Server1 缓存真实服务器密钥，或者如果有，StrictHostKeyChecking则已被禁用或忽略。
由于 SSH + Kerberos GSS-API 依赖 SSH 进行数据加密，因此您的假设是，如果对 Server1 的身份验证成功，中间人恶意 SSH 服务器就可以访问所有传输的信息，因为 SSH 不在 SSH 加密上使用基于 Kerberos 的数据加密。
是的，理论上这是可行的，但前提是你的恶意 SSH 服务器 Server2 能够成功冒充 Server1 的客户端。
我认为真正的 Server1 会拒绝（或至少应该拒绝）转发的凭据。作为 Kerberos 身份验证的一部分，客户端发送两条消息，服务票证和验证器.虽然转发的服务票有效，但随附的身份验证器无效。
RFC 4121SSH 使用的 Kerberos GSS-API 规范将通道绑定信息作为身份验证器消息的一部分：
“通道绑定标签旨在用于识别 GSS-API 安全上下文建立令牌所针对的特定通信通道，从而限制攻击者可以重复使用被拦截的上下文建立令牌的范围。”
即，Authenticator 消息包含发送者的 IP 地址和源端口，以及目标 IP 地址和端口号。如果这些与实际连接不匹配，则 Server1 应拒绝 Kerberos 交换。