I have been attempting to create a way to ssh into a machine hiding behind a firewall. I set up my ssh client with the option Proxycommand /usr/bin/ncat -l 2000, and then I connect it to sshd with ncat <client> 2000 -c "sshd -i" on the server. It works in that I can get a shell on the server, but the server sends a different key than when I use normal ssh. So the question is, why? Is the key different when sshd is called in this unusual way?

  • I'm not quite sure how your network setup looks like.. Are you connecting from a client to the firewall on port 2000? Give us a clearer idea what you do on the server and what you do on the client... – MLu Jul 3 '13 at 10:50
  • I'm fairly certain the network is irrelevent – Robbie Mckennie Jul 3 '13 at 10:54
  • I'm not overly familiar with the ProxyCommand functionality in ssh(d) but the above configuration sounds backwards to me. Why would the client be listening for connections? Why would the server know about the client IP address ahead of time? It would seem to me that the client ssh_config should specify the ncat that connects to a port on the server, no? – Etan Reisner Jul 3 '13 at 11:29
  • That's exactly the point. The server is behind a firewall, so it can't listen for ssh connections. – Robbie Mckennie Jul 3 '13 at 12:11

In my test case it's not different:

~$ ssh -v localhost
debug1: Server host key: ECDSA 59:ca:86:5a:c0:01:f9:8e:31:3e:0b:8e:cf:ad:2b:fa

~$ ssh -v localhost -p 2000
debug1: Server host key: ECDSA 59:ca:86:5a:c0:01:f9:8e:31:3e:0b:8e:cf:ad:2b:fa

Where on the port 2000 it's invoked as /usr/sbin/sshd -i from xinetd.

Maybe in your case it reads a different config file? Try adding -f /etc/ssh/sshd_config to the ncat command line and see if it helps.

Solution: Apparently sshd was using a different key when invoked from ncat, sshd -i -h /etc/ssh/ssh_host_ecdsa_key does the trick.

  • If i do as you did i get the expected result. The error only comes about when connecting under these specific circumstances. Although, when i next get the chance i'll try what you've suggested – Robbie Mckennie Jul 3 '13 at 12:15
  • Also, i can't imagine posting that key is safe, unless you've garbled it. Or it's safe because it's some kind of hash value and i'm just a moron – Robbie Mckennie Jul 3 '13 at 14:31
  • @RobbieMckennie - no worries, it's a hash of the public part of the server key, see en.wikipedia.org/wiki/Public-key_cryptography for info about Public Key Cryptography. Actually there is a way to store these hashes in DNS for host verification, see simon.butcher.name/archives/2011/01/16/… so it's by all means a non-sensitive info. – MLu Jul 3 '13 at 22:04
  • Adding -f /etc/ssh/sshd_config didn't help – Robbie Mckennie Jul 4 '13 at 2:03
  • 1
    Can you do /usr/sbin/sshd -i -h /etc/ssh/ssh_host_ecdsa_key to force it to use the right key? – MLu Jul 4 '13 at 4:57

Uncomment the HostKey /etc/ssh/ssh_host_ecdsa_key line in /etc/ssh/sshd_config to have sshd -i use the correct key.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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