所以我本质上想这样做:
ssh [email protected] -t ssh bob2@test-vm
如果我只是将它放入终端,上述操作就可以正常工作,但是我很难尝试通过 .ssh 配置文件复制它。
以下是配置文件中的内容:
Host bastion
HostName 35.192.152.35
User bob2
Host test-vm
User bob2
FOrwardAgent yes
ProxyCommand ssh bastion nc %h %p 2> /dev/null
但是它会出现一个错误,提示“权限被拒绝”,公钥文件无效?我从这篇文章中得出了上述结论: https://unix.stackexchange.com/questions/124078/how-to-ssh-to-a-server-using-another-server-with-key-from-the-second-server
不知何故,这对那个人来说是有效的,但对我来说似乎不起作用。我还尝试在 sshd_chroot 配置中允许代理转发和 TCP 转发,以及在所有各方(源、堡垒和服务器)上,但这并没有什么区别。
如果我强制指定身份路径:
Host bastion
HostName 35.192.152.35
User bob2
IdentityFile /Users/bob/.ssh/id_rsa
Host test-vm
User bob2
FOrwardAgent yes
ProxyCommand ssh bastion nc %h %p 2> /dev/null
IdentityFile /home/bob2/.ssh/id_ed25519
然后它出现了同样的错误,另外还说找不到目录“/home/bob2/.ssh/id_ed25519”
有人有什么想法吗?
答案1
一旦您意识到堡垒是为了击败网络防火墙而不是为了存储密钥,您就可以将其更改为具有最少配置的 2 个命令解决方案。
在本地机器 A 上,确保 ssh-agent 已运行。
对 B 执行一次性命令,其中 B 具有以下配置:
Host B
ForwardAgent yes
User proxyuser
并运行以下命令:
$ ssh B ssh-add # and possibly a reference to a non-standard key
此时,您的本地 ssh 代理将在其缓存中拥有远程密钥。
之后,简单的-J
或ProxyJump
将C
“正常工作”:
Host C
User user
ProxyJump proxyuser@B
$ ssh C
尽管额外的一次性命令略有不便,但在我看来,您可以保持您的配置非常合理。
你可以问自己一个问题,如果密钥无论如何都会缓存在你的本地机器上,那么将密钥存储在堡垒上是否真的能为你提供额外的安全性。当然,这样做有一点好处不是将密钥存储在磁盘上,但如果您的本地机器被黑客入侵,读取文件或与加载了密钥的 ssh 代理通信就没有太大区别了。
答案2
看起来您希望您的配置让 test-vm 在堡垒中查找密钥。因此我建议:
- 将密钥文件复制到堡垒机中 bob2 的 .ssh 文件夹。
- 添加代理命令在您的配置中使用 ssh-add。
答案3
下面的方法对我有用...几乎和你的一样,只是我指定了最终目的地的 IP 地址(可能与你的情况无关)并且我必须复制从堡垒到我的本地主机的密钥,因为我的 ssh_config 正在这里而不是在堡垒中途找到密钥文件:
==== added to .ssh/config ====
Host mybastion
HostName 133.35.41.9
User bastuser
IdentityFile /Users/bchapman/.ssh/bast_priv.key
Host mytarget
HostName 109.0.1.38
ProxyCommand ssh -q -W %h:%p mybastion
User targuser
IdentityFile /Users/bchapman/.ssh/targ_priv.key
==============
之后我可以 ssh mytarget、scp localfile mytarget: 等