Internal SSH client does not support all features of ~/.ssh/config, ProxyJump/ProxyCommand

[gdevenyi]

I'm trying to use the session manager to smooth connecting and launching the VNC server via an SSH tunnel.

In my SSH configuration I use a ProxyCommand/ProxyJump command so that I can directly run ssh normally and the connection will be tunnelled.

Host workstation
  #ProxyCommand ssh -W %h:%p mygateway #Old SSH versions
   ProxyJump mygateway #Newer ssh versions

https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Jump_Hosts

i.e. I can run ssh user@workstation which the ssh client will transparently perform: ssh -> mygateway -> ssh -> workstation All features such as port forwarding (-L and -R) transparently work as though I am directly connected to workstation, I do not need to add any extra settings.

Thus, I would like to similarly do: vncviewer user@worksation

Which will honour my ssh configuration and do: ssh -> mygateway -> ssh -> workstation -> launch vncserver && forward ports

If you go looking around the net, there are loads of documentation on doing this process manually with TurboVNC and similar clients, this would be a massive improvement to the session manager.

[dcommander]

I think it would probably be easier to figure out how to make the Session Manager work with external SSH clients, which already support jump hosts, than it would be to figure out how to implement ProxyJump/ProxyCommand with JSch. The original JSch code base is basically abandoned, so I can only really extend it by implementing features from scratch (which is difficult) or borrowing them from the JSch fork.

In fact, referring to #321, you can already use ExtSSH with the Session Manager. It just causes two SSH sessions to be created, one by JSch for the Session Manager itself and a second by the external SSH client for the SSH-tunneled RFB connection. That means that SSH authentication occurs twice, which isn't optimal, and the Via parameter is only honored for the SSH-tunneled RFB connection. Ideally, if ExtSSH is specified, the Session Manager should use the OpenSSH ControlMaster feature to preserve the initial SSH connection for reuse by the SSH-tunneled RFB connection. Then it would be a matter of repurposing the TurboVNC Viewer's Via parameter so that it populates the -J option to OpenSSH. That would probably also trigger me to revisit the legacy VNC_VIA_CMD and VNC_TUNNEL_CMD interfaces and create a more user-friendly interface for customizing the external SSH command.

Conceptually, the setup would work kind of like this (although the actual Session Manager would have to handle multiple sessions rather than assuming only one session on Display :1):

$ ssh -o ControlMaster=auto \
  -o ControlPath=\"~/.ssh/turbovnc-session-manager-%C\" -o ControlPersist=60 \
  -J {gateway-host} {turbovnc-host} \
  "/opt/TurboVNC/bin/vncserver -list | grep \:1 || /opt/TurboVNC/bin/vncserver"
$ ssh -o ControlPath=\"~/.ssh/turbovnc-session-manager-%C\" \
  -o ControlPersist=60 \
  -J {gateway-host} -axf -L {free local port}:localhost:5901 {turbovnc-host} sleep 20

However, I would also want to extend the feature so that it supports SSH forwarding using Unix domain sockets, since TurboVNC 3.1 now has that ability. Conceptually it's straightforward, but it would require a lot of testing, so ideally I would like to secure funding.

Closing this issue in favor of #148, but let me know if, for some reason, my proposal wouldn't solve the problem from your point of view.

[gdevenyi]

In fact, referring to #321, you can already use ExtSSH with the Session Manager. It just causes two SSH sessions to be created, one by JSch for the Session Manager itself and a second by the external SSH client for the SSH-tunneled RFB connection.

I saw this issue, but I couldn't sort out if this would apply to me as the user failed to ever provide any examples of commands/configurations he was using. I have tried to use -ExtSSH but it always seemed to ignore it (for 3.1-20231117 at least), if I was trying to use the session manager interface, it always directly internal SSH'd to the host.

I agree the enhancements and procedure in general make sense for the Linux/Mac user, my concern about external SSH is a Windows user probably won't have that available, and be locked out of the next-gen features planned.

[dcommander]

Ideally the feature would work with Microsoft's OpenSSH implementation. I need to play around with it and see if I can eliminate the need for SSH forking (the -f option), since only Cygwin's OpenSSH implementation supports that on Windows (but Cygwin doesn't support ControlMaster.)

Unfortunately extending JSch to handle ProxyJump/ProxyCommand probably won't happen unless someone else adds the feature to the aforementioned JSch fork. Since I don't have a deep familiarity with the JSch code base, figuring out how to implement such a major feature myself would likely take more labor than anyone is willing to pay me for.