Internal SSH client does not support all features of ~/.ssh/config, ProxyJump/ProxyCommand about turbovnc HOT 3 CLOSED

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.

from turbovnc.

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.

from turbovnc.

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.

from turbovnc.