1

I'm trying to get my SSH connections to go through mitmproxy using the following SSH config file:

Host test
        HostName 10.0.0.246
        User testssh
        ProxyCommand socat - PROXY:10.0.0.211:%h:%p,proxyport=9090

This results in the following verbose output and the connection just hangs after the last line:

OpenSSH_8.9p1 Ubuntu-3ubuntu0.1, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /home/ubuntu/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Executing proxy command: exec socat - PROXY:10.0.0.211:10.0.0.246:22,proxyport=9090
debug1: identity file /home/ubuntu/.ssh/id_rsa type 0
debug1: identity file /home/ubuntu/.ssh/id_rsa-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_ecdsa type -1
debug1: identity file /home/ubuntu/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/ubuntu/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_ed25519 type -1
debug1: identity file /home/ubuntu/.ssh/id_ed25519-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_ed25519_sk type -1
debug1: identity file /home/ubuntu/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_xmss type -1
debug1: identity file /home/ubuntu/.ssh/id_xmss-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_dsa type -1
debug1: identity file /home/ubuntu/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.1

I see no connections in my mitmproxy console. Just running socat - PROXY:10.0.0.211:%h:%p,proxyport=9090, however, actually makes a connection and I am able to see it in my proxy console:

$ socat - PROXY:10.0.0.211:10.0.0.246:22,proxyport=9090
SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.3

I have also tried using corkscrew and nc, but both have the same behaviour -- SSH hangs, but directly invoking the commands makes a connection.

It appears the connection just hangs forever with no further logs from ssh. What can I try to debug this further?

EDIT: The machine is able to connect directly without any trouble if I remove the ProxyCommand setting.

EDIT: According to man ssh_config:

This directive is useful in conjunction with nc(1) and its proxy support. For example, the following directive would connect via an HTTP proxy at 192.0.2.0:

ProxyCommand /usr/bin/nc -X connect -x 192.0.2.0:8080 %h %p

As mentioned earlier, I have tried this and more and it made no difference:

Host test
        HostName 10.0.0.246
        User testssh
        #ProxyCommand corkscrew 10.0.0.211 9090 %h %p
        #ProxyCommand socat - PROXY:10.0.0.211:%h:%p,proxyport=9090
        ProxyCommand /usr/bin/nc -X connect -x 127.0.0.1:8080 %h %p
4
  • is there any guides to using mitproxy for SSH on the mitproxy site? looks like mitmproxy is for http, websockets etc, not for SSH which is a completely different protocol to the former Jul 26, 2023 at 6:13
  • That is true; I am just trying a few things to validate some ideas. I assumed it would at least try to connect with the tunnel. It is executing the ProxyCommand (I can see it in htop), but no actual connection happens. I am not sure what is blocking it when it is being executed by ssh. Directly running the command shows me a TCP tunnel being opened in mitmproxy.
    – Ragesh
    Jul 26, 2023 at 6:22
  • man ssh_config also says "This (the ProxyCommand) directive is useful in conjunction with nc(1) and its proxy support. For example, the following directive would connect via an HTTP proxy at 192.0.2.0". I've tried the same nc command from there and still no connection.
    – Ragesh
    Jul 26, 2023 at 6:48
  • @JaromandaX it looks like you were right. Even though nc on its own works, when it's being called by ssh, it immediately sends a version string which confuses the heck out of mitmproxy. I naively assumed that the CONNECT tunneling would allow this to work but it looks like it needs more work. Thanks for the pointer!
    – Ragesh
    Jul 26, 2023 at 8:16

1 Answer 1

0

It looks like this was indeed a case of the proxy server itself not knowing how to handle the tunneling for SSH. I was able to verify from the proxy's logs that it was running into errors and terminating the remote half of the connection, but leaving the client side open and hanging. This explains why no amount of SSH verbosity could provide any answers.

1
  • Its quite possible to route an ssh (or any arbitrary TCP port) via an HTTP proxy - just prefix the exchange with "CONNECT $TARGET:$PORT HTTP/1.1" with some basic error checking - corkscrew does this for ssh - which you seem to have tried already?
    – symcbean
    Jul 26, 2023 at 10:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .