How can I see the proxy configurations of an SSH command in git bash?

Question

I'm having issues with SSHing through a corporate proxy.

In my Windows environment - SSH works fine:

$ ssh -v [e-mail]
OpenSSH_7.5p1, OpenSSL 1.0.2k  26 Jan 2017
debug1: Reading configuration data /c/Users/davidj/.ssh/config
debug1: /c/Users/davidj/.ssh/config line 2: Applying options for github.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to github.com [192.30.255.112] port 22.
debug1: Connection established.
...

Now in my Windows taskbar, there's an ISA Server Firewall client. If I uncheck 'Enable Microsoft Firewall Client for ISA Server' then my SSH attempt will fail.

$ ssh -v [e-mail]
OpenSSH_7.5p1, OpenSSL 1.0.2k  26 Jan 2017
debug1: Reading configuration data /c/Users/davidj/.ssh/config
debug1: /c/Users/davidj/.ssh/config line 2: Applying options for github.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to github.com [192.30.255.112] port 22.
debug1: connect to address 192.30.255.112 port 22: Connection timed out

So this is all well and good for working in the Windows environment - I just need to enable the firewall client.

My problem is that I'm trying to work within a Ubuntu VM on Virtual Box.

The Virtual Box network adapter is NAT, with no port forwarding.

In the VM HTTP traffic works fine, so long as I've set network proxy for HTTP and HTTPS in Ubuntu.

However, SSH here will give me connection refused:

david@david-VirtualBox:~$ ssh -vvv [e-mail]
OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/david/.ssh/config
debug1: /home/david/.ssh/config line 2: Applying options for github.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "github.com" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to github.com [192.30.255.113] port 22.

Is there a way of debugging here how my Windows is able to SSH to the outside world?

Answer 1

I would do the following:

On the Windows host machine I would run a wireshark (on port 22). Then try to connect from the linux guest machine via ssh. You will not see the guest connecting to outside.

The reason?

The Virtual Box network adapter is NAT, with no port forwarding.

You have to have port forwarding if you have NAT.

You can do it the following way: configure Virtualbox to open a port 22 on your host with IP 127.0.0.1 (loopback dev on your host) and forward it to your internal IP e.g. 10.0.10.10 (the internal address of your VM, which I do not know from your information.)

Afterwards, you will be able to connect to outside.

Edit - to deal with ISA Server

Forgot to write about the ISA part. For that you will probably need a cygwin environment and OpenSSH server:

This is taken from here

To quote:

*** My dirty solution:

Linux <--> Windoz with ISA client <--> Windoz with ISA server

On my Windoz with ISA client:

I install Cygwin Environment + OpenSSH server (http:/pigtail.net/LRP/printsrv/cygwin-sshd.html).

I configure my ISA Client (WSPCFG.INI and CREDTOOL.EXE).

WSPCFG.INI in C:\cygwin\usr\sbin (SSHD.EXE folder): [sshd] Persistent=1 KillOldSession=1 ForceCredentials=1

C:\Program Files\Microsoft Firewall Client\CREDTOOL.EXE -w -n sshd -c myusername mydomainname mypassword (myusername, mydomainname and mypassword must be ISA server credentials)

On my Linux:

ssh -fND1080 myusername:mypassword@mywindozisaclientname (myusername and mypassword must be an account for Windoz with ISA client)

So I create a dynamic port forwarding (ssh behaves as a socks server).

I configure my mail client program (PROXY SOCKS = localhost , PORT = 1080)

Answer 2

Your firewall client? In the corporate world the term endpoint security is very popular. Such (vpn) software manipulates the routing tables on the client machine in such a way that other networks become unreachable when active. Yet when active connections are OK. A solution in such cases is to install this firewall client of yours in the guest VM.