堡垒服务器：使用 TCP 转发 VS 将私钥放在服务器上

Question

我们有堡垒服务器 B。我们需要使用私钥从 A 通过 B 到 C 的 SSH。

什么是更好的选择：

• 将私有 SSH 密钥放在服务器B上。我们了解到在生产环境中这样做是个坏主意。

  从这里：

  永远不要将您的 SSH 私钥放在堡垒实例上。相反，使用 SSH 代理转发首先连接到堡垒，然后从那里连接到私有子网中的其他实例。这使您可以将 SSH 私钥保存在您的计算机上。

• 使用SSH 代理转发。为了设置代理转发，我需要允许 TCP 转发。设置代理转发时，会在转发主机上创建一个套接字文件，这是密钥可以转发到目的地的机制。在 AWS 的堡垒设置中：

  TCP 转发：将此值设置为 true 将启用 TCP 转发（SSH 隧道）。这可能非常有用，但也存在安全风险，因此我们建议您保留默认（禁用）设置，除非需要

  也从这里：

  SSH 代理转发被认为是有害的

什么是更好的？第二个链接的替代方法：ProxyCommand，我知道它有助于解决套接字文件问题，但我仍然认为我必须启用 TCP 转发，所以它足够安全吗？

Answer 1

使用 ProxyCommand 或 ProxyJump

我建议使用ProxyCommand（或者甚至更好，ProxyJump因为语法更简单，但我认为在客户端需要 openssh 7.3+），并且您不需要在堡垒上部署私钥，一切都保持在本地。

ProxyJump 示例

在您的客户端计算机上，您编写一个~/.ssh/config与以下内容类似的文件：

Host bastion
  HostName bastion.example.com
  User bastion-user
  Port 22
  IdentityFile ~/.ssh/id_bastion

Host srvC
  HostName srvC.local
  User server-user
  IdentityFile ~/.ssh/id_protected_lan
  ProxyJump bastion

然后这样做ssh srvC将通过 B（堡垒）将您连接到 C，无需代理转发，也不会将私钥部署到堡垒。

在上面的例子中，“bastion”是你的堡垒主机的别名，srvC 是你的服务器 C 的别名。HostName你需要为你的主机输入 IP 或真正的完全限定域名。对于用户，您需要更新User堡垒和服务器 C 上的正确登录名。最后，IdentityFile如果您使用本地代理（例如 KeeAgent 或 ssh-agent），这是可选的，但如果它没有运行，那么它也会工作并询问您每个关键密码。

部署公钥

当然你需要部署的公共密钥都堡垒和SRVC。您可以使用（$ 符号只是为了说明提示，请勿键入）：

$ ssh-copy-id -i ~/.ssh/id_bastion.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   bastion
$ ssh-copy-id -i ~/.ssh/id_protected_lan.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   srvC

注意：只有在仍然允许密码身份验证的情况下，以上才有效。在上述部署并验证一切正常后，您应该禁止在 2 个服务器上进行密码验证。

使用 ProxyCommand 而不是 ProxyJump 的示例

如果您有不支持ProxyJump（在客户端）的旧版 OpenSSH ，请替换：

ProxyJump bastion

经过

ProxyCommand ssh -q -W %h:%p bastion

据我了解，这是相似的。

Answer 2

我看到了关于 ProxyJump 的答案。让我们谈谈ProxyCommand。

但是等等，等等！我可以写信给你如何破解使用代理转发的服务器，这样会更容易理解差异！

让我们破解！

对于基本步骤：您可以在这里阅读我的帖子

基本步骤如下：

1. 创建堡垒用户
2. 禁用root登录
3. 阻止黑客攻击
4. 更改端口
5. 配置防火墙
6. 配置 SELinux

如何使用代理转发

- 在 ~/.ssh/config 中创建配置

  Host bast
        Hostname BASTION_IP
        ForwardAgent yes
        User bastion

- 将您的身份验证密钥添加到 ssh-agent

ssh-add ~/.ssh/name_rsa

- 连接到堡垒主机

ssh bast

- 从堡垒连接应用服务器

 ssh app@IP -p PORT

黑客！

你可能会问我这个问题：

• 我的服务器安全吗？答案很简单：

  • 不！

• 为什么？

  • 因为你使用的是SSH代理转发！

• 问题出在哪里？

  • 因为代理转发是危险的，它被认为是有害的。

• 为什么？

  • 让我们彻底解释一切：当您连接堡垒主机时，您的 ssh-agent 将被转发。这意味着将设置套接字以便有人可以使用此套接字数据访问您的服务器。想象一下你的堡垒服务器被入侵了，如果有人在你的 Linux 服务器上有足够的权限，他/她只会使用你的套接字信息。因此，您的所有服务器都可以访问。我知道妥协的窗口非常小，因为这取决于您连接到堡垒主机的时间。但是，当您有其他选择（例如 ProxyCommand）时，您真的想冒险吗？因此，只需使用 ProxyCommand！

如果您破坏了堡垒主机，如何破解服务器？

跟踪目标

在 /tmp 目录中，您可能会看到类似的内容：

[root@localhost tmp]# ll
total 12
drwx------  2 bastion bastion 4096 Sep  7 17:35 ssh-mKX88v0Vlo

让我们打开临时文件

[root@localhost tmp]# cd ssh-mKX88v0Vlo/
[root@localhost ssh-mKX88v0Vlo]# ll
total 0
srwxr-xr-x 1 bastion bastion 0 Sep  7 17:35 agent.10507

让我们看看与此进程 ID 的连接。

netstat -nxp | grep  10507

结果：

unix  [ ]   STREAM     CONNECTED     501384   10507/sshd: bastion

和谁有联系？

lsof -i -a -p 10507

结果：

COMMAND  PID   USER  FD  TYPE DEVICE SIZE/OFF NODE NAME
sshd    10507 bastion  3u  IPv4 501301  0t0  TCP *IP*:ssh->*IP*:8279 (ESTABLISHED)

我们还可以看到套接字文件：

cd /proc/10507/fd/
ls

结果：

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

而会发生什么时，客户端将连接到远程服务器？让我们来看看：

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:48 11 -> socket:[502267]
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

我们甚至可以使用 netstat 查看是否使用了套接字文件：

unix  3 [ ]  STREAM  CONNECTED  502267  10561/sshd: 
                     bastion  /tmp/ssh-oVoMXC6vb8/agent.10561
unix  3  [ ] STREAM     CONNECTED     502072   10561/sshd:  bastion 

窃取套接字信息和 IP 地址

现在我们需要在堡垒主机的会话打开时窃取套接字信息。哦，我们还需要目标服务器 IP，所以只需使用 netstat ：

netstat -tn

使用转发的套接字文件的最后一步

eval "$(ssh-agent -s)"
SSH_AUTH_SOCK=/tmp/ssh-EAKxOdL4fl/agent.10507

检查密钥是否已加载。

ssh-add -l

结果应该是这样的：

2048 SHA256:2Psdl..B5KQ /home/usr/.ssh/name_rsa (RSA)

服务器被黑了，如何解决安全问题？

代理命令

Host app
    Hostname *.*.*.*
    IdentityFile ~/.ssh/your_rsa
    User *******
    Port ****
    ProxyCommand ssh -W %h:%p bast

Host bast
     Hostname *.*.*.*
     ForwardAgent no
     User ******

对于基本操作：如何通过服务器传输文件（从客户端到服务器，从服务器到客户端），您可以在这里阅读我的帖子

结论

• 如果您使用堡垒主机，请不要使用 AgentForwarding 而是使用 ProxyCommand
• 始终使用非 root 用户进行身份验证
• 使用防火墙并阻止所有不必要的连接。
• 使用 SELinux（一般情况下）
• 阻止多次尝试使用错误凭据登录的 IP 地址
• 如果没有必要，不要给用户 sudo 权限
• 监控您的服务器
• 更新您的服务器以获取安全补丁

更多信息，请参见我的博客。另外我有一些截图，所以它可能对你有帮助。