0

There is a jump host, called via ProxyCommand, to access some servers. In the .ssh/config file there is a Host definition for each server and the command for the jumphost (with %r and %h coming from the Host configuration) :

Host myserver
    Hostname myserver.mydomain.net
    User technic
    port 22
    ProxyCommand ssh -x -p 22 jumpuser@jumphost ssh -6 -p 22 -x %r@%h "nc localhost %p"

Accessing the jumphost and then issuing the ssh <host> command works and prompt me to confirm the connection. Then the following connections work fine even via jumphost.

If I instead try to connect directly via jumphost I get no prompt for authenticity confirmation and I just get a

key_load_public: No such file or directory Host key verification failed.

I use the following versions: OpenSSH_6.9p1 and LibreSSL 2.1.8.

Do I need to first make a manual connection (manual connection to jumphost + manual connection to server) to each server, in order to have them work correctly afterwards?

Or is there some setting for prompting me to confirm the connection even at the first connection via jumphost? (without upgrading OpenSSH)

  • What jumphost method are you using, exactly? – grawity Jan 9 at 15:54
  • ProxyCommand ssh -x -p 22 jumpuser@jumphost ssh -6 -p 22 -x %r@%h "nc localhost %p" (with %r and %h coming from the Host configuration) – Kamafeather Jan 9 at 15:56
  • Please update your question with this information. // Why not use -J? No need to make this work manually. – Daniel B Jan 9 at 15:58
  • Updated with it. There is no -J option in my ssh. What does it do? And how can I make it work without that option? (assuming it is possible to skip the initial step I wrote about above) – Kamafeather Jan 9 at 16:02
  • I use OpenSSH_6.9p1, LibreSSL 2.1.8. I cannot find the option you mentioned in the manual. – Kamafeather Jan 9 at 16:07
2

That's not connecting "directly". With your current configuration, you are actually making two SSH connections to the destination host. One SSH client runs on the jumphost, another runs on your local machine (talking to the destination through the former), and the error message is produced by the latter.

Your local client still works the same as before, but the remote (jumphost) client is run in non-interactive mode – it has no pseudoterminal, and even if it did, all its input/output is attached to your local client's "network side". So there is no way the remote client can produce a visible prompt (it would be misinterpreted by your local client as malformed SSH traffic) nor receive the confirmation input.

You can avoid this only by removing the second (redundant) connection completely, and simplifying your ProxyCommand to one of:

ProxyCommand ssh -W %h:%p jumpuser@jumphost

ProxyCommand ssh -x jumpuser@jumphost "nc -6 %h %p"

ProxyCommand ssh -x jumpuser@jumphost "socat stdio tcp6:%h:%p"

ProxyCommand ssh -x jumpuser@jumphost "(cat <&\$fd & cat >&\$fd) {fd}<>/dev/tcp/%h/%p"

Of these methods, prefer ssh -W if available, use nc/ncat/socat otherwise, try the cat $fd hack as last resort. (If the jumphost forbids ssh -W and has no nc nor ncat nor socat, try to talk with your IT team about why they're deliberately making it harder to use the jumphost properly.)

  • I will ask it for sure; ...when they will be back from holidays 😅 – Kamafeather Jan 9 at 16:27
  • Perfect deductions. I tried the second example and it works flawlessly, and not even asking me anymore to confirm the authenticity! (I guess because the jumphost already verified it when connecting to other servers). Thank you! 😃👍🏼 – Kamafeather Jan 9 at 16:45
  • 1
    No; in all of these examples, the SSH protocol runs directly between your client and the final destination, and the jumphost is not involved in the verification at all – it only carries the data across. (This is practically identical to "TCP forwarding" using ssh -L.) – grawity Jan 9 at 17:21

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.