跳转主机上的 SSH ForceCommand 有多安全？

Question

我的网络中有以下设置：

Internet <--> Bastion <--> Local Network

我有几个用户，每个用户都分配到一台特定的机器。或者换句话说：每个用户必须只能访问这些服务器之一。例如：User1 --> Machine1、User2 --> Machine2 等等。

这些用户将从我的网络外部连接，我已经考虑了许多选项如何通过我的堡垒主机将他们的连接转发到我的网络。

最终我选择了 Match Blocks 和 forcecommand。

所以，我在堡垒上的 /etc/ssh/sshd_config 看起来像这样：

Match User User1
        ForceCommand ssh User1@Machine1 $SSH_ORIGINAL_COMMAND

User1 连接到堡垒主机，堡垒主机自动与 Machine1 建立连接。

据我了解 ForceCommand，User1 不会真正访问堡垒主机，因为他的所有操作都将首先由 match 块处理，因此重新路由到 Machine1。然而这是真的吗？这是否已经足以成为一个安全的设置？无论如何，用户在 Machine1 上被监禁，所以他在那里不会有很多可能性。

Answer 1

我使用堡垒主机的方式是使用ProxyCommand和-W这个例子中的标志：

ssh -o ProxyCommand='ssh -W %h:%p user@bastion' user@machine

出于安全原因，我使用这种方法。客户端和目标机器之间的通信是端到端加密和身份验证的，这意味着即使堡垒遭到破坏，它也能保持安全。一个受损的堡垒主机提供的安全性不亚于在没有堡垒的情况下使用端到端的 ssh。

它还消除了使用任何代理转发的需要。客户端可以首先使用基于密钥的身份验证来访问堡垒，然后再次访问目标主机，而无需向其中任何一个提供可用于滥用客户端上存在的私钥的代理连接。

它还限制了我在堡垒主机上依赖的代码。我根本不需要在堡垒上执行任何命令。-W意味着没有命令标志以及一个单端口转发，这个端口转发是堡垒主机需要允许的。

考虑到这种方法，我的建议是尽可能地锁定堡垒主机，只允许使用上述结构的命令。

在~/.ssh/authorized_keys对堡垒文件可以由root拥有（如均能从文件系统到它的根路径上的目录），这样可减少即使有人设法在突破作为非特权用户可能被修改的风险堡垒主机。

在authorized_keys客户端的权限可以通过使用选项command、no-agent-forwarding、no-pty、no-user-rc、no-X11-forwarding以及permitopen用于限制端口转发以仅允许访问该用户被允许访问的主机上的端口 22 来限制。

原则上，即使多个用户在堡垒上共享一个用户名，这种方法也是安全的。但是通过在堡垒上使用单独的用户名，您可以获得更多的分离。

Answer 2

我想大多数时候这都很好，但安全问题是还没有人抽出时间去考虑的事情。没有任何保证。

例如，很长一段时间以来，没有人认真思考如何从 bash 中的环境变量创建函数，但最近人们意识到这可能会被颠覆，其影响之一是可以绕过 ForceCommand（在如果用户的 shell 是 bash，则至少在authorized_keys 文件中实现。Bash 已修复，希望您的版本是最新的，但发生了类似的事情。

我不完全确定定义 ForceCommand 是否与在authorized_keys 文件中定义这些命令实际上相同。我还没有仔细看过。