我們有堡壘伺服器 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，而無需代理轉發，也無需將私鑰部署到堡壘。

在上面的範例中，“bastion”是您的 Bastion 主機的別名，srvC 是您的伺服器 C 的別名。HostName您需要為您的主機輸入 IP 或真正的完全限定域名。對於使用者，您需要User在堡壘和伺服器 C 上更新正確的登錄名。最後，IdentityFile如果您使用本地代理（例如 KeeAgent 或 ssh-agent），這是可選的，但如果它沒有執行，那麼它也會工作並詢問您每個關鍵密碼。

部署公鑰

當然，您需要將公鑰部署到bastion 和 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

據我了解，這是相似的。

引用自：https://serverfault.com/questions/958222