首先,介绍一些背景。
今天,如果您处于一个主要由 Windows Server AD 组成且只有少量 Linux 服务器的环境中,那么您可以选择通过 SSH 向服务器进行身份验证:
- 使用证书认证通过 SSH 管理 Linux 服务器(常规 Linux 方式)
- 将 Linux 服务器加入到您的 AD 域 (realm+sssd),并通过 SSH 使用用户名/密码验证来管理它们
问题是,选项 1 让管理员管理与环境的其余部分分开的一组凭据,而选项 2 让管理员在机器完全相互识别之前通过网络直接向远程服务器提供密码。
在 Windows 世界中,这个问题通过网络级身份验证得到解决(至少对于 RDP 来说,我知道应该避免这种情况)。该过程的简化版本如下所示:
- 用户开始连接远程计算机
- 远程计算机使用 AD 计算机帐户令牌进行响应
- 本地计算机验证令牌,查看 NLA 支持,并向用户显示凭证对话框
- 用户使用凭证完成对话
- 本地计算机使用域控制(而不是远程计算机)验证凭据
- DC 向本地计算机提供身份验证令牌
- 本地计算机向远程计算机出示令牌
- 远程计算机根据域验证令牌
- 如果成功,则允许用户访问远程计算机。
实际上,这个过程可以更简单,用户首次登录本地计算机时为其创建的现有身份验证令牌已经可以使用。
这是一个复杂的过程,我描述它时肯定犯过错误。重点是身份验证令牌取代了 Linux 故事中的证书,这样用户就永远不会向可能未知的机器提供实际凭据。此外,各方对受信任 DC 的依赖使事情比 Linux 故事更好,因为用户不必管理自己的证书,甚至不需要通过他们自己的软件(而是为他们提供的软件)。
现在来回答这个问题。有没有办法获得类似的功能来对加入 AD 的 Linux 服务器进行 SSH 会话身份验证,其中服务器永远不会看到用户凭据,但用户体验仍然是 Windows 原生凭据验证?
答案1
要解决的问题很多,但本质上需要的是“kerberized” SSH 或其他任何东西。NLA 还提供了一个额外的步骤(此处未指定),即在身份验证通过之前不提供控制台会话(创建控制台会话在资源方面很昂贵)。
更重要的是,除了令人望而却步的复杂性之外,我对此并不感兴趣,因为已经有了解决方法。使用堡垒跳转主机作为 Linux 主机的前端,禁止来自其他主机的访问/端口类型。该堡垒主机可以是 Windows,并支持所有缺少的功能。
堡垒跳转主机在 AD 环境中也变得越来越普遍,因为它允许通过 RDP 等方式访问受保护的资源。
同样,对于 RDP 示例,凭据实际上并未受到服务器的保护。可以使用 /RemoteGuard 开关解决这个问题。
https://learn.microsoft.com/en-us/windows/security/identity-protection/remote-credential-guard
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/mstsc