Description
VSCode Remote SSH Support for Proxy servers, when the proxy has a unique connection syntax - containing remote tunnel port.
Motivation
In order to enforce Authentication and Authorization in large organizations, there is a need to connect using ssh through a Proxy server.
Some SSH Proxy Servers - like Cyberark's PSM SSH Proxy product, have unique syntaxes to allow a connection to multiple targets using the same proxy server.
Syntax Example
Cyberark PSM SSH Proxy
A regular Tunneling connection - directly to the target:
ssh -L <local port>:127.0.0.1:<vscode remote port> <target user>@<target address>
However, using a Proxy server (Specifically the CyberArk's PSM For SSH),
in order to Connect though this product with Tunneling, there is a unique syntax:
ssh -L <local port>:127.0.0.1:<known proxy constant port> <Organizational user>@<target user>@<target address># 22#<vscode remote port>@Proxy_IP
As can be seen - there are two major gaps:
- The remote port used in the -L option (or equivalents like -D) is known ahead of time: which is <vscode remote port> when connecting directly, and <known proxy constant port> when connecting via CyberArk's PSM For SSH.
- The <vscode remote port> is passed inside the connection string (specifically - the username of ssh is '<Organizational user>@<target user>@<target address># 22#<vscode remote port>') when connecting via CyberArk's PSM For SSH.
Suggested Gaps Solutions
(1) Constant Tunnel instead of vscode remote port
The Tunnel on the LocalForwarding part (as specified by the -D option) should no longer be the remote port the VSCode agent listens on, but a known ahead port.
Please note that the ssh configuration of LocalForward, which allows configuring the ssh local forwarding ahead of time is not sufficient - as the port on the Client side needs to be known ahead - which is not the case for VSCode.
(2) Tunnel In Connection Username
Currently - the extension uses the ssh configurations Hostname and User parameters
As the tunnel port is now inside the Username part it will should look like:
Host YourAliasName
HostName ProxyServer
User ORG_USER@TARGET_USER@TARGET_ADDRESS#22#\<vscode remote port\>
However - currently the Remote VSCode Agent uses a Random port - meaning there is no way to know ahead of time what the port is.
This can be solved by, using a configurable and predefined known remote port for the remote VSCode Agent.
Description
VSCode Remote SSH Support for Proxy servers, when the proxy has a unique connection syntax - containing remote tunnel port.
Motivation
In order to enforce Authentication and Authorization in large organizations, there is a need to connect using ssh through a Proxy server.
Some SSH Proxy Servers - like Cyberark's PSM SSH Proxy product, have unique syntaxes to allow a connection to multiple targets using the same proxy server.
Syntax Example
Cyberark PSM SSH Proxy
A regular Tunneling connection - directly to the target:
ssh -L <local port>:127.0.0.1:<vscode remote port> <target user>@<target address>
However, using a Proxy server (Specifically the CyberArk's PSM For SSH),
in order to Connect though this product with Tunneling, there is a unique syntax:
ssh -L <local port>:127.0.0.1:<known proxy constant port> <Organizational user>@<target user>@<target address># 22#<vscode remote port>@Proxy_IP
As can be seen - there are two major gaps:
Suggested Gaps Solutions
(1) Constant Tunnel instead of vscode remote port
The Tunnel on the LocalForwarding part (as specified by the -D option) should no longer be the remote port the VSCode agent listens on, but a known ahead port.
Please note that the ssh configuration of LocalForward, which allows configuring the ssh local forwarding ahead of time is not sufficient - as the port on the Client side needs to be known ahead - which is not the case for VSCode.
(2) Tunnel In Connection Username
Currently - the extension uses the ssh configurations Hostname and User parameters
As the tunnel port is now inside the Username part it will should look like:
However - currently the Remote VSCode Agent uses a Random port - meaning there is no way to know ahead of time what the port is.
This can be solved by, using a configurable and predefined known remote port for the remote VSCode Agent.