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

有什么更好的选择：

• 将私密SSH密钥放在服务器 B 上。我们了解到，在生产环境中执行此操作不是一个好主意。

  从这里：

  切勿将SSH私钥放在堡垒实例上。而是使用SSH代理转发来首先连接到该堡垒，然后再从那里连接到私有子网中的其他实例。这样，您就可以仅在计算机上保留SSH私钥。

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

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

  也从这里：

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

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

使用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，而无需代理转发或将私钥部署到堡垒。

在上面的示例中，“堡垒”是堡垒主机的别名，而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

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

使用ProxyCommand代替ProxyJump的示例

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

ProxyJump bastion

通过

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

据我了解，这是相似的。

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

但是等等，等等！我可以写信给您，介绍如何破解使用代理转发的服务器，这将更容易理解它们之间的区别！

骇客！

基本步骤：您可以在这里阅读我的文章

基本步骤如下：

1. 创建堡垒用户
2. 禁用root登录
3. 阻止黑客入侵
4. 变更港口
5. 配置防火墙
6. 配置SELinux

如何使用AgentForwarding

-在〜/ .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权限
• 监控您的服务器
• 更新您的服务器以获取安全补丁

有关更多信息，请参见我的博客。此外，我还有一些screeenshots，因此可能对您有帮助。

只需像大多数其他人一样使用SSH代理转发。

• 密钥将在笔记本电脑上的ssh代理中。
• 您登录到堡垒，并通过代理进行了身份验证。
• 从那里登录到目标主机，并将身份验证请求转发回您的笔记本电脑。

优点：堡垒上没有存储任何可滥用的密钥。

希望有帮助:)