☰

SSH 配置选项是否使用 ProxyJump 网关的 `/etc/hosts` 查找？

tag-icon • tag-icon ssh
SSH 配置选项是否使用 ProxyJump 网关的 `/etc/hosts` 查找？

我正在尝试通过服务器进行网关跳跃A -> B -> C，并希望将此连接作为我的 SSH 配置中的条目。

从 A 到 B 的 SSH 操作是可行的。然后从 B 到 C 也是可行的ssh B -t ssh C。

但是，当我尝试使用以下 SSH 配置文件时，失败了。

Host B
    Hostname B

Host C
    Hostname C
    ProxyJump B

Host *
    User username
    ForwardAgent yes
    PKCS11Provider /usr/lib/ssh-keychain.dylib

当详细运行这个程序时，我发现我遇到了一个问题

debug1: getpeername failed: Bad file descriptor

这个答案似乎问题是由于未找到 C 的查找（即在文件内/etc/hosts）。当我查看/etc/hostsB 上的内容时，列出了我想要连接的所有最终主机位置（包括 C）。所以我相信我希望我的连接/etc/hosts在建立最终连接时使用 B 的列表。有没有办法在 A 的 SSH 配置中指定这一点？

请注意，我在任何机器（A、B 和 C）上都没有 root 权限。

调试日志：

username@A ~ % ssh C -v  
OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/username/.ssh/config
debug1: /Users/username/.ssh/config line 14: Applying options for C
debug1: /Users/username/.ssh/config line 19: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Setting implicit ProxyCommand from ProxyJump: ssh -v -W '[%h]:%p' B
debug1: Executing proxy command: exec ssh -v -W '[C]:22' B
OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/username/.ssh/config
debug1: /Users/username/.ssh/config line 19: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to B [111.111.111.111] port 22.
debug1: Connection established.
debug1: provider /usr/lib/ssh-keychain.dylib: manufacturerID <Apple, Inc.> cryptokiVersion 2.20 libraryDescription <Keychain emulation PKCS#11 API> libraryVersion 0.0
debug1: provider /usr/lib/ssh-keychain.dylib slot 0: label <Key For PIV Authentication (Use> manufacturerID <Apple, Inc.> model <Keychain> serial <000000> flags 0x404
debug1: have 1 keys
debug1: provider /usr/lib/ssh-keychain.dylib slot 1: label <Key For Digital Signature (User> manufacturerID <Apple, Inc.> model <Keychain> serial <000000> flags 0x404
debug1: have 2 keys
debug1: identity file /Users/username/.ssh/id_rsa type -1
debug1: identity file /Users/username/.ssh/id_rsa-cert type -1
debug1: identity file /Users/username/.ssh/id_dsa type -1
debug1: identity file /Users/username/.ssh/id_dsa-cert type -1
debug1: identity file /Users/username/.ssh/id_ecdsa type -1
debug1: identity file /Users/username/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/username/.ssh/id_ed25519 type -1
debug1: identity file /Users/username/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/username/.ssh/id_xmss type -1
debug1: identity file /Users/username/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: provider /usr/lib/ssh-keychain.dylib: manufacturerID <Apple, Inc.> cryptokiVersion 2.20 libraryDescription <Keychain emulation PKCS#11 API> libraryVersion 0.0
debug1: provider /usr/lib/ssh-keychain.dylib slot 0: label <Key For PIV Authentication (Use> manufacturerID <Apple, Inc.> model <Keychain> serial <000000> flags 0x404
debug1: have 1 keys
debug1: provider /usr/lib/ssh-keychain.dylib slot 1: label <Key For Digital Signature (User> manufacturerID <Apple, Inc.> model <Keychain> serial <000000> flags 0x404
debug1: have 2 keys
debug1: identity file /Users/username/.ssh/id_rsa type -1
debug1: identity file /Users/username/.ssh/id_rsa-cert type -1
debug1: identity file /Users/username/.ssh/id_dsa type -1
debug1: identity file /Users/username/.ssh/id_dsa-cert type -1
debug1: identity file /Users/username/.ssh/id_ecdsa type -1
debug1: identity file /Users/username/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/username/.ssh/id_ed25519 type -1
debug1: identity file /Users/username/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/username/.ssh/id_xmss type -1
debug1: identity file /Users/username/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to B:22 as 'username'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes128-ctr MAC: [email protected] compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: [email protected] compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:XXXXXXXXXXXXXXXXXXXXXXX
debug1: Host 'B' is known and matches the ECDSA host key.
debug1: Found key in /Users/username/.ssh/known_hosts:5
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: Will attempt key: /usr/lib/ssh-keychain.dylib RSA SHA256:YYYYYYYYYYYYYYYYYYYYYYYYY token agent
debug1: Will attempt key: /usr/lib/ssh-keychain.dylib RSA SHA256:ZZZZZZZZZZZZZZZZZZZZZZZZZ token agent
debug1: Will attempt key: /Users/username/.ssh/id_rsa 
debug1: Will attempt key: /Users/username/.ssh/id_dsa 
debug1: Will attempt key: /Users/username/.ssh/id_ecdsa 
debug1: Will attempt key: /Users/username/.ssh/id_ed25519 
debug1: Will attempt key: /Users/username/.ssh/id_xmss 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /usr/lib/ssh-keychain.dylib RSA SHA256:YYYYYYYYYYYYYYYYYYYYYYYYY token agent
debug1: Server accepts key: /usr/lib/ssh-keychain.dylib RSA SHA256:YYYYYYYYYYYYYYYYYYYYYYYYY token agent
debug1: pkcs11_provider_unref: 0x111111111111 refcount 3
debug1: pkcs11_provider_unref: 0x111111111111 refcount 2
debug1: Authentication succeeded (publickey).
Authenticated to B ([111.111.111.111]:22).
debug1: channel_connect_stdio_fwd C:22
debug1: channel 0: new [stdio-forward]
debug1: getpeername failed: Bad file descriptor
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: exec
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Port forwarding disabled.
debug1: Remote: User rc execution disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Port forwarding disabled.
debug1: Remote: User rc execution disabled.
channel 0: open failed: administratively prohibited: open failed
stdio forwarding failed
ssh_exchange_identification: Connection closed by remote host

/etc/ssh/ssh_config

Host *
    SendEnv LANG LC_*
    ForwardX11 yes
    ForwardX11Trusted yes
    XAuthLocation /opt/X11/bin/xauth

答案1

当您连接到任何主机时，查找是在您的本地主机上完成的，而不是远程主机，所以我建议忘记/etc/hosts并确保HostName主机 C 具有正确的 IP/DNS。

另外，您是否使用跳转：

    ProxyCommand ssh -W %h:%p B

我注意到你在评论中反过来使用了它

答案2

在缺乏任何其他解释的情况下，我相信问题在于您缺少反向 DNS 条目，也许是通过中的一行/etc/hosts。

我建议/etc/hosts在所有三台计算机上进行更新，以便它们彼此了解。

答案3

我在这里运行以下配置：
~/.ssh/config（my_host 的）

Host C
    HostName            192.168.3.1     # ip of Host C
    ProxyCommand        ssh -W %h:%p B
    ServerAliveInterval 60

Host B
    HostName            192.168.2.1     # ip of Host B
    ProxyCommand        ssh -W %h:%p A
    ServerAliveInterval 60

Host A
    HostName            192.168.1.1     # ip of Host A
    ServerAliveInterval 60

这提供了这样的连接：
“my_host”->“主机 A”->“主机 B”->“主机 C”

如果使用 DNS 名称而不是 IP 地址，则需要确保每个主机都可以解析下一个主机的 DNS 名称。-
> 您的主机可以解析主机 A 的 DNS 名称
-> 主机 A 可以解析主机 B 的 DNS 名称
-> 主机 B 可以解析主机 C 的 DNS 名称

如果您只需要一跳，并且示例的主机 A 是您的工作站，则主机 A 的以下 /ssh/config 应该执行：

Host C
    HostName            192.168.3.1     # ip of Host C
    ProxyCommand        ssh -W %h:%p B
    ServerAliveInterval 60

Host B
    HostName            192.168.2.1     # ip of Host B
    ServerAliveInterval 60

答案4

我也遇到了同样的问题。

就我的情况而言，名称解析完全按照预期工作。

原因是中间主机上的 TCP 端口转发被禁用。因此，解决方案是在中间主机的 /etc/ssh/sshd_config 中将 AllowTcpForwarding 更改为 yes

就我而言，sshd_config 文件中有几个 Match 子句，因此我必须在多个地方更改 AllowTcpForwarding。

相关内容