When using ProxyCommand in Windows when creating the tunnel a new window appears

[lars18th]

This is previously commented here: #149 (comment)
But I repost here as new issue.

• VSCode Version: 1.32.0-insider (in Portable mode)
• Local OS Version: Windows 7 x64 Pro
• Remote OS Version: Debian 9.9
• Remote Extension/Connection Type: SSH

Steps to Reproduce:

1. Configure your .ssh/config with something like connect.exe -S proxy-server:1080 %h %p
2. Start your SSH Remote Session in a new window.
3. In the first SSH connection the VSCode opens the new window and connects with the remote server.
4. In the seccond SSH connection the VSCode launches the remote server.
5. BUT, in the third SSH connection, the one that stablishes the TUNNEL, a NEW window appears in the local computer related to the connect.exe helper tool.

The problem is related to the solution used to launch the third SSH command. The expected behaviour is to run it in background.
Please, fix this bug.

Thank you!

[d2inco]

Having the same issue.

[lars18th]

Having the same issue.

I hope they solve it in the next release. At time, the issue isn't market as "bug". ⚠️

[lars18th]

Please @roblourens , can you label this issue as BUG ?

Thank you!

[roblourens]

I haven't had time to try this but can you explain what connect.exe is?

a NEW window appears in the local computer related to the connect.exe helper tool.

What is this window, what does it show? A vscode window?

[d2inco]

Rob, whether you use connect.exe, nc.exe, or ssh.exe as the ProxyCommand for an SSH connection, the problem is that VSCode opens a new window to run that ProxyCommand, instead of running either silently, or within a Terminal window (within VSCode)

[d2inco]

@roblourens - sorry, missed the 2nd half of the question... The window remains empty. In the background it has established the tunnel (through whichever of the methods) and the ssh command to the host where the managed-source code is rides across that tunnel. A snapshot is attached, but it of course shows no content because there is no visible traffic within that TTY; it's all tunneled.

[roblourens]

Ok, I'm not sure why that window is showing up. vscode simply runs an ssh command and windows or ssh does the rest.

[d2inco]

So it is probably SSH that is causing the window to be started, since it is the command within the "ProxyCommand" that is causing it.

I'm a Linux guy, not a Windows guy, so I'm not sure what "side-effect" causes a command execution to happen in a window, instead of being captured by the parent process (VSCode) of the initial SSH.exe command. I'm guessing that it is the method that VSCode is opening the SSH Process. If I run the same ssh far-box by hand, it executes the ProxyCommand transparently without spinning up any extra windows.

If this were Linux, then it might be a side effect of STDERR not being captured, or something like that. Is there a similar concept in Windows that would cause the extra window to open?

[lars18th]

Hi @roblourens ,

I haven't had time to try this but can you explain what connect.exe is?

connect.exe is /c/Program Files/Git/mingw64/bin/connect.exe
However, the same problem appears when you use ncat.exe

Off-topic: I suggest that Microsoft includes a native proxy helper (connect, ncat or any other) inside the Win32-OpenSSH distribution. It's a pain to require an external tool to drive the native OpenSSH client.

a NEW window appears in the local computer related to the connect.exe helper tool.

What is this window, what does it show? A vscode window?

@d2inco has explained: a new CMD terminal is open.

Ok, I'm not sure why that window is showing up. vscode simply runs an ssh command and windows or ssh does the rest.

I'm sure you're not doing this call (the one to open the SSH tunnel) in the same way as the previous (the two SSH connections to open the session to the server and start the service). The "SSH client" is executed three times, and just only one (the last that opens the tunnel) is causing this issue.

Please, mark this as BUG. And do this simple test to check it:

• Connecto with the SSH client to ANY SSH server that has access to the Internet, and make a socks tunnel (ssh -D 1080 user@any-server.org).
• Then configure your SSH Client to access to your VSCode SSH server using the Socks server over the tunnel with adding this to your .ssh/config:

Host my-server-tunneled
    HostName my-server.com
    User user
    ProxyCommand C:\Program\ Files\Git\mingw64\bin\connect.exe -S 127.0.0.1:1080 %h %p

Or if you use NetCat for Windows:

Host my-server-tunneled
    HostName my-server.com
    User user
    ProxyCommand C:\NC64\ncat.exe --proxy-type socks4 --proxy 127.0.0.1:1080 %h %p

• And finally use the VSCode SSH plugin to open the session "my-server-tunneled".

You see now the problem?

[darkrush]

Same problem appeared on my computer, my config file is like:

Host jump
ForwardAgent yes
HostName jump_server_ip
User username

Host target_server
ForwardAgent yes
HostName target_server_ip
User username
ProxyCommand C:\Windows\System32\OpenSSH\ssh.exe -q -W %h:%p jump

When I connect to target_server, a new pure black window with caption “C:\Windows\System32\OpenSSH\ssh.exe” is created. Just same as the picture post by @d2inco

Fortunately, the remote function is working properly, I have not seen any problem yet since I am a shallow vscode user.

[lars18th]

Same problem appeared on my computer, my config file is like:

ProxyCommand C:\Windows\System32\OpenSSH\ssh.exe -q -W %h:%p jump

When I connect to target_server, a new pure black window with caption

So using ssh.exe, connect.exe and ncat.exe with the ProxyCommand originates the same trouble. That's certifies that the problem isn't the tool but the call to the SSH executable to stablishing the tunnel.

I hope this bug will be solved in the MAY release (not included at time in the milestone): https://github.com/microsoft/vscode-remote-release/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22May+2019%22).

[roblourens]

Can you tell me whether this happens if you set remote.SSH.showLoginTerminal? My guess is that it's because connect.exe just needs a terminal.

[lars18th]

Can you tell me whether this happens if you set remote.SSH.showLoginTerminal? My guess is that it's because connect.exe just needs a terminal.

Ohhh!!!!

If I set remote.SSH.showLoginTerminal then the NEW window doesn't appear. Futhermore, I don't see any data in the terminal.

Futhermore, I have configured Cygwin/Bash as my default Terminal. Perhaps this is related.

And I need also to comment that the connect.exe tool (and ncat.exe and ssh.exe as well) don't need any terminal as they work in full background as a helper tool.

In any case: I feel you're using a call to the Terminal for stablishing the Tunnel. And this is incorrect! The SSH command for the tunnel needs to be executed exactly as the rest of the initial SSH commands. Why you use the Terminal Shell to start it?

I feel like we're close to finding the cause of this bug.
Regards.

[roblourens]

And I need also to comment that the connect.exe tool (and ncat.exe and ssh.exe as well) don't need any terminal as they work in full background as a helper tool.

In theory it seems that should work but in practice I understand a lot of windows tools expect a cmd environment and will open a window if they are not started in one.

In any case: I feel you're using a call to the Terminal for stablishing the Tunnel.

When you set that setting we are, and that's why it works. The other SSH commands are started in terminals all the time so we can intercept their authentication prompts.

Given all of this I don't think there's anything else I can do for now but recommend using that setting. It's likely that in the future we will always use a terminal by default.

[d2inco]

One problem/difference that I noted as I was trying to debug this last week was that when I Do Not have the "run in a terminal" explicitly set, I get the SSH Passphrase prompt at the top of the VSCode window, and the phrase gets added to the SSH Agent automatically, so things mostly work (other than the lingering window ... oh and that SSH_agent does not get passed to remote GIT for push/pull)... But, when I DO have "run in a terminal" set, then the SSH Passphrase gets asked in the terminal, and the key does NOT get added to the SSH Agent, so then I end up having to respond to the passphrase prompt on Every. Single. Operation.... which makes it pretty unusable.

[roblourens]

If the key is in your ssh agent and the agent is running and accessible from vscode's environment, then you shouldn't be asked for the passphrase on every operation when using the terminal. But vscode won't add the key to the agent automatically in that scenario.

[d2inco]

It was running. The only diff between the scenarios was when I toggled the run-in-terminal.

[roblourens]

Is it possible that you started the agent after vscode was started? I'm thinking that in theory the processes should have the same environment in the two cases but maybe when running in the terminal it has the old environment which is missing $SSH_AUTH_SOCK

[d2inco]

it should already have been running. I can try to play with it tomorrow to see if I can recreate it.

[darkrush]

Can you tell me whether this happens if you set remote.SSH.showLoginTerminal? My guess is that it's because connect.exe just needs a terminal.

It worked，An SSH Tunnel terminal created inside VSCode. No more window created outside. Thank you!

[pd93]

Can confirm that remote.SSH.showLoginTerminal works. However, VS Code automatically opens with the 'SSH tunnel' terminal open. I'm quite used to tapping CTRL+' immediately after opening VS Code and getting a new shell session. Unfortunately, this fix doesn't allow for that.

@roblourens Would it be plausible to add a setting to get VS Code to hide this terminal session? or to move it to the Output tab?

[roblourens]

Could you try this with vscode insiders, and the nightly ssh extension, and without that setting? Due to some changes I think it should work as you expect now. I forgot about this workaround when I commented in your other issue 😁

[lars18th]

Hi @roblourens ,

Could you try this with vscode insiders, and the nightly ssh extension, and without that setting? Due to some changes I think it should work as you expect now. I forgot about this workaround when I commented in your other issue

Sorry, NO! Tested with the last version of VSCode Insiders and the last version of the plugin, and the same problem continues: when stablishing the SSH TUNNEL a COMMAND window appears. The only workaround until now is to use the remote.SSH.showLoginTerminal = YES.

I hope you can fix it.
Thank you!

[pd93]

@roblourens Can confirm that removing the remote.SSH.showLoginTerminal setting and using the latest VSCode Insiders and nightly SSH extension works. The blank window does not appear!

My only (very minor) criticism it that an integrated terminal session is still created on startup (albeit with my preferred shell this time) which differs to the standard behaviour of a blank window with no integrated terminal. I could definitely live with this if I had to though and is a great improvement over the pop up window.

@lars18th make sure you have the nightly version of the extension rather than just the latest stable.

[lars18th]

@lars18th make sure you have the nightly version of the extension rather than just the latest stable.

How to install the nightly version of the extension? I use the nightly version of the VSCode, but I don't know about the Remote-SSH extension.

[pd93]

@lars18th Just search for it like you would any other extension. (I uninstalled the stable version first, just in case of any conflict).

[lars18th]

Hi,

I confirm that with the Remote-SSH (Nightly) the problem is GONE! ✌️
Futhermore, I don't see any command window on startup as @pd93 comments.

Thank you Rob for fixing it! 👍

PD: If you (@pd93 & @roblourens) want I can close this issue.

[pd93]

Strange that we get different behaviour with the integrated terminal opening.

Just to clarify what I'm talking about..
Both screenshots are taken after opening an empty folder on my remote server (after going through a ProxyJump server).

Stable VS Code with latest stable Remote SSH:

No integrated terminal session started, but has an pop-up terminal window.

Insiders VS Code with nightly Remote SSH:

Integrated terminal automatically starts up, but the pop-up window is gone.

[roblourens]

Integrated terminal automatically starts up, but the pop-up window is gone.

If the terminal was open before, then it will be persisted as open the next time you open a window. Are you sure that's not just what you're seeing?

Thanks for testing this though. I will close this.