如何使用 ssh 和双因素获得持久身份验证?

如何使用 ssh 和双因素获得持久身份验证?

我正在尝试让管理员和开发人员尽可能轻松地过渡到双因素身份验证。一个障碍是每次客户端打开会话时都需要输入第二个因素。有没有一种方法可以实现 ssh 的双因素身份验证,其中第二个因素只需每天输入一次或其他某个相当长的时间段?

这个想法是为需要 2FA 的 ssh 设置跳转主机。然后可以使用跳转主机提供对其他服务器的访问(ssh -J JumpHost TargetHost),而这些服务器将被限制为仅接受来自跳转主机的连接。

在我的环境中,理想情况下,首次登录跳转主机需要公钥、密码或 Kerberos TGT 以及第二个因素。在指定时间段内,后续登录同一台服务器只需要第一个因素。

到目前为止,我已经检查了 Duo 和 Okta。Duo 尚未就持久性问题回复我,从他们的文档中看不出它甚至可以做到。Okta 可以做到这一点,但我发现了一种劫持用户凭据的方法——甚至可以跨客户端计算机——所以这是一个不太有吸引力的选择。

答案1

如果第二个因素是通过 PAM 完成的(而不是通过强制的后认证命令),则可以插入自定义 PAM 模块来跟踪成功的身份验证并跳过与 2fa 相关的 PAM 模块。我不确定这样的 PAM 模块是否已经存在(但它可能与 pam_faillock 非常相似,一个模块负责检查,另一个模块负责跟踪)。

(PAM 配置中的“扩展语法”允许一种前向转到,例如auth [success=1 default=ignore] pam_localuser.so通常用于1本地用户跳过下一个模块。)

然而,这可能没有必要,因为 SSH已经支持持久身份验证,采用长寿命多路复用连接的形式。初始身份验证后,SSH 客户端可以打开任意数量的通道/会话 - 让同一连接全天保持活动状态。

例如,在 OpenSSH 配置中ControlPath(以及可选的ControlPersist)允许启用多路复用,而 PuTTY 在“连接→SSH→共享 SSH 连接”下也有相同的功能。相同的连接可以承载交互式 shell 会话、批处理命令、TCP 隧道和 SFTP 传输。

这不仅避免了第二因素的要求,甚至避免了第一的因素(因为连接已经过身份验证)。大多数 SSH 服务器默认允许此功能,除非明确禁用 - 因此在大多数情况下,这已经是可能的,无需系统管理员的参与,只需要客户端配置即可启用它。

相关内容