Allow specifying the port for ssh gateway seperately

[gdevenyi]

Following up on #372

A minimal ~/.ssh/config with ProxyJump config works as expected now (if I drop the config problems from #439) where my config looks like:

Host gateway
  User myusername
  HostName my.gateway.tld
  Port something-not-22
Host targetmachine
	ProxyJump gateway

However, the pure command line and GUI versions of vncviewer it doesn't appear to be possible to configure vncviewer to use a different port for the SSH gateway (non 22 port) than for the SSH target machine (22 port).

(Removing ~/.ssh/config temporarily for testing)

If I specify -SSHPort <other than 22> on the command line, I can't tell if the gateway port is using that, or not, the logs don't provide enough detail, even at maximum loglevel.

[dcommander]

The logs do in fact tell you the SSH port and username for all SSH hops, regardless of the logging level. You should see something like:

SSH: Connecting to {gateway-host} port {gateway-SSH-port} with username {gateway-user}
SSH: Connecting to {vnc-host} port {vnc-SSH-port} with username {vnc-user}

Regarding the behavior of SSHPort, please refer to my notes here: #393 (comment). tl;dr: SSHPort sets the SSH port for all hops. The only way to specify a different SSH port for each hop is to use an OpenSSH config file. I had two overall design options for the feature:

Option 1:

• Repurpose the Via parameter to specify an SSH jump host, which makes sense because the Via parameter was already used for specifying gateway hosts.
• When using SSH tunneling without the Session Manager, change the default behavior of Via so that it creates a two-level SSH tunnel all the way to the VNC host, as opposed to creating an SSH tunnel to the gateway host and forwarding the RFB connection directly from the gateway host to the VNC host.
• Allow the behavior of Via to be reverted by setting the turbovnc.viajump system property to 0.
• Upsides:
  • This is essentially a deprecation model. The historical behavior of Via predates the OpenSSH jump host feature, it doesn't provide end-to-end encryption, and it requires opening RFB ports in the VNC host's firewall. Repurposing Via allows us to address those limitations automatically with no loss of functionality.
  • The default SSH tunneling behavior is consistent across all connection types (TurboVNC Session Manager, TCP ports, Unix domain sockets.) Tunnel creates a one-level SSH tunnel, and Via creates a two-level SSH tunnel by default. (Previously, Via created a two-level SSH tunnel for Unix domain socket connections, a one-level SSH tunnel for TCP port connections, and didn't work at all with the Session Manager.)
• Downsides:
  • Because Via can also be used to specify UltraVNC Repeater gateways, postfixing the parameter value with :{gateway-SSH-port} or ::{gateway-SSH-port} would be misinterpreted as an UltraVNC Repeater display or port. Thus, there is no way to use the Via parameter to specify the SSH port of the jump host.

Option 2:

• Introduce a new Jump parameter for specifying an SSH jump host.
• Use the Via parameter only for creating an SSH tunnel to the gateway host and forwarding the RFB connection directly from the gateway host to the VNC host, or for specifying an UltraVNC Repeater gateway.
• Upsides:
  • The jump host's SSH port could be specified by postfixing the Jump parameter value with :{gateway-SSH-port}.
• Downsides:
  • It would be necessary to use a different parameter (Jump rather than Via) when using the TurboVNC Session Manager to connect to a VNC host behind an SSH gateway. Via would continue to fail with the Session Manager.
  • When using SSH tunneling without the Session Manager, the use of Via or Jump would silently affect the end-to-end encryption of the connection, but the overall functionality would be the same.
  • For Unix domain socket connections, Jump and Via would be identical, since Unix domain socket connections must always use SSH jump hosts.
  • All of the above would be hard to document and confusing for end users.

UltraVNC Repeater gateways are essentially a deprecated feature that may be removed or hidden behind another system property in the future, which would open up the possibility of specifying a gateway SSH port in the Via parameter. There are no immediate plans to remove the traditional Via behavior, but I want to steer users away from it. Thus, Option 1 made more sense from a usability point of view, since it makes the new behavior opt-out rather than opt-in.

Possible stopgap solutions:

1. I could introduce another system property (turbovnc.ultravncrepeater) that disables the UltraVNC Repeater functionality entirely, but that functionality would be enabled by default.
2. I could introduce another parameter (ViaSSHPort) for specifying the SSH port of the jump host separately.

I prefer (1).

[dcommander]

@gdevenyi I am willing to introduce a workaround for you, but TurboVNC 3.2 beta is imminent, so I need timely feedback on this and the other issues you filed. Otherwise any additional changes will have to wait until a future release.

[gdevenyi]

The only way to specify a different SSH port for each hop is to use an OpenSSH config file.

This works for my personal use case, but I'd like to use TurboVNC for a more general set of remote access from OSX/Windows where setting up SSH config will not be straightforward.

I prefer (2), assuming that a GUI field can be exposed for this at the same time.

[dcommander]

Upon further consideration, two system properties and a parameter is more complex than two parameters, so that would undercut my justification for choosing Option 1. I am going to go ahead and change the Via parameter so that it allows specifying an SSH port by default. Thus, it will be necessary to set turbovnc.viajump to 0 in order to use an UltraVNC Repeater.

[dcommander]

Upon even further consideration, hiding the UltraVNC Repeater functionality behind turbovnc.viajump would have created a backward compatibility issue, for reasons cited in the commit log for ae1c3fa. Furthermore, the additional complexity around turbovnc.viajump would have undercut my documentation arguments against Option 2. Thus, I went ahead and implemented Option 2.

Notes:

• When using the built-in SSH client (including when using the Session Manager), the new Jump parameter and the ProxyJump OpenSSH configuration keyword do not support specifying multiple comma-separated SSH hops. Supporting that would be tricky at best and definitely not something I would be willing to do pro bono. However, specifying multiple comma-separated SSH hops is supported when using an external SSH client. (When using an external SSH client, the %G pattern in the SSH command-line template is populated with the literal value of Jump or Via.)
• For compatibility with OpenSSH, -J can be used as an alias for the Jump parameter.
• Via is effectively an alias for Jump when using the Session Manager with SessMgrAuto enabled (thus addressing one of my arguments against Option 2) or when using Unix domain socket connections, except that Via does not allow a separate gateway SSH port to be specified without using an OpenSSH config file. If SessMgrAuto is disabled, then Via acts like Jump when making the Session Manager's SSH connection, but it acts like Via when making the final connection to the VNC server. (In other words, it uses a multi-level SSH tunnel for the Session Manager but a single-level SSH tunnel for the RFB connection.)
• Jump is not yet exposed in the GUI. That is forthcoming. This issue will remain open until that work is complete.

[gdevenyi]

I can confirm that the new GUI configuration and ssh gateway feature works 👍 thanks so much