Vscode-remote-release: Support custom ssh ports

Created on 30 May 2019  路  11Comments  路  Source: microsoft/vscode-remote-release

  • VSCode Version: 0.37.0
  • Local OS Version: mac 10.12.1
  • Remote OS Version: CentOS 7
  • Remote Extension/Connection Type: SSH

Steps to Reproduce:

  1. Setup the listening port of the SSH server to a customize port, for instance 2222, on a CentOS 7 machine.
  2. Create a configure for the CentOS 7 machine on your VS Code
  3. Connect to the CentOS 7 machine using the remote-ssh plugin
  4. Connection failed due to the command generated at the last step, like the error messages below:

"install" terminal command done
Received install output: 328eec1c-fde8-4360-9584-ea6fc711aae3==45144==
Server is listening on port 45144
Spawning tunnel with: ssh XXX -N -L localhost:41280:localhost:45144
Spawned SSH tunnel between local port 41280 and remote port 45144
Waiting for ssh tunnel to be ready
Could not establish tunnel to "XXX (Max wait time exhausted).
Could not establish tunnel to "XXX" (Max wait time exhausted).

The correct command for spawning tunnel with ssh should be
* ssh XXX -p 2222 -N -L localhost:41280:localhost:45144*


Does this issue occur when you try this locally?: Yes
Does this issue occur when you try this locally and all extensions are disabled?: Yes

feature-request ssh verification-needed verified

Most helpful comment

Now I will try to parse the port number after a colon in the "Connect to host" dialog, and in the URI passed to --folder-uri.

Also fixed the issue mentioned above where some characters will break the install script on windows. For example, a remote named foo:bar should now work on windows.

All 11 comments

You have to configure this on your end. It should work if you set Port 2222 in your ssh config file.

You have to configure this on your end. It should work if you set Port 2222 in your ssh config file.

I have created a configure with a customized port on my side, otherwise, the first step of connection will not pass. The problem happens at the last step when a tunnel is going to be created between my side and the server side without correct port configuration.

ssh XXX -p 2222 If you have the port set in your ssh configuration then the -p is not necessary, same as every ssh command.

@roblourens Understood. But there are pretty common scenarios where the destination is fleeting. It happens a lot with containers and chroots (contrast some cloud server). You might even have 22 _and_ 2222 on the same destination IP. You _can_ edit your ssh_config but that blows zero-config out the water.

Humble request is to support URI format, which is nice and clean and avoids CLI parameter unpleasantness. For example ssh://192.168.0.233:2222. This is analogous to how git: URIs work, instead of punting: "we just do git on 22, edit your ssh_config".

That's a fair point, in your workflow are you using some other port often?

Actually this may already work, if I run "Connect to host" and enter ssh://myhost:22 it is handled fine. We just pass this input to ssh on the command line and ssh knows how to parse it.

That's a fair point, in your workflow are you using some other port often?

Mostly just today, laugh. Googled it and landed here. Use case is WSL related, where some folks consider sharing localhost with Windows a feature not a bug ref WSL#4199. [Yes, existence VS Code's WSL Remote plugin. Different topic, longer story.]

I tried the URI first natch (thinking I was clever) but it didn't take. The is with a Windows VS Code and Windows OpenSSH. Possibly bug between keyboard and seat, but less likely. Floats for me on screencap below. 172.18.2.49:2222 is quite reachable, natch.

image

I do see the problem on windows, we are trying to write a script to a file with the hostname in its path, and not handling some characters properly.

Failed to write install script to path C:\Users\roblou\AppData\Local\Temp\vscode-linux-multi-line-command-ssh:\168.62.29.176:22-795961560.sh

I think i'm looking for the same ability: specify custom ports when the service connects back to the remote system over the (currently) randomly generated port.

iptables on my system works as a whitelist, so everything is blocked by default. In the OP scenario above, adding a rule for 45144 would have allowed it to work for me. However, the next time it connects, the port will be different, and not in the exceptions list, so vscode will fail to make the connection after the ssh tunnel occurs.

@umdstu that is a different request but please file an issue for it, we could do that.

Now I will try to parse the port number after a colon in the "Connect to host" dialog, and in the URI passed to --folder-uri.

Also fixed the issue mentioned above where some characters will break the install script on windows. For example, a remote named foo:bar should now work on windows.

Was this page helpful?
0 / 5 - 0 ratings