Commit db3d30dcad breaks automatic tunnelling.

[Parakleta]

In db3d30d you changed the tunnelling handling with the session manager to not change the provided option, but rather to use a local variable calculation. This then breaks behaviour in the fillCmdPattern() method is Tunnel.java since it is still looking at the manually set option rather than using the session manager behaviour. The documentation in Params.java says that the tunnel options if "effectively set" when the session manager is being used, but this is no longer entirely true.

turbovnc/java/com/turbovnc/vncviewer/Tunnel.java

Lines 284 to 285 in f2b115f

	case 'H':
	command += (opts.tunnel ? gatewayHost : remoteHost);

turbovnc/java/com/turbovnc/vncviewer/Tunnel.java

Lines 308 to 309 in f2b115f

	if (!opts.tunnel && !gFound)
	throw new ErrorException("%G pattern absent in tunneling command template.");

[dcommander]

The code prior to that commit did not change opts.tunnel in Tunnel.java, so I don't understand what the issue is. Can you provide an example of the breakage?

[Parakleta]

In CConn.java the opts.tunnel option is no longer forced true when the session manager is used. This is worked around in the createTunnel() method in Tunnel.java by the local tunnel variable, but this variable is not propagated into the fillCmdPattern() method in the same file.

The side effect of this is that the two referenced lines now operate differently to before that change. That is, the %H replacement no longer contains the username, and the %G token must be provided in the tunnel command or else an error is thrown.

[Parakleta]

This is not necessarily a problem, except that it is a breaking change that isn't documented, and in fact the relevant documentation for the tunnel option suggests that it should be automatically set by the session manager. See:

turbovnc/java/com/turbovnc/rfb/Params.java

Lines 830 to 835 in 473e569

	public static BoolParameter sessMgrAuto =
	new BoolParameter("SessMgrAuto",
	"When using the TurboVNC Session Manager, the default behavior is to " +
	"automatically enable OTP authentication and SSH tunneling. Disabling " +
	"this parameter overrides that behavior and allows any security " +
	"configuration to be used.", true);

and

turbovnc/java/com/turbovnc/rfb/Params.java

Lines 874 to 884 in 473e569

	public static BoolParameter tunnel =
	new BoolParameter("Tunnel",
	"Setting this parameter is equivalent to using the Via parameter with an " +
	"SSH gateway, except that the gateway host is assumed to be the same as " +
	"the VNC host, so you do not need to specify it separately. When using " +
	"the Tunnel parameter, the VNC host can be prefixed with {user}@ to " +
	"indicate that username {user} (default = local username) should be used " +
	"when authenticating with the SSH server.\n " +
	"When using the TurboVNC Session Manager, this parameter is effectively " +
	"set unless the SessMgrAuto parameter is disabled.", false);

[dcommander]

I don't understand your point. External SSH clients are not yet supported with the Session Manager. (See #148.) The modes that should work are:

• Internal SSH client with Session Manager
• Internal SSH client with explicit SSH tunneling (i.e. Tunnel parameter set)
• External SSH client with explicit SSH tunneling

If one of those modes does not work, then please provide exact steps to reproduce the failure.

[dcommander]

Ah. I think I see the issue. When VNC_TUNNEL_CMD is set, the createTunnel() function assumes that an external SSH client will be used, which is the wrong assumption when the session manager is active. Stand by.

[Parakleta]

Please don’t disable that mode of behaviour. I’ve been using it successfully for over a year and rely on it.

[dcommander]

Why is the built-in SSH client unsuitable for your needs? If you're using the Session Manager, then you are already using the built-in SSH client to connect to the host and manage sessions. The external SSH client only comes into play when you connect to a session. The Session Manager expects that the built-in SSH client will be used. Thus, it leaves the SSH tunnel open, the assumption being that the viewer will reuse the tunnel for the actual connection. As currently implemented, using ExtSSH with the Session Manager would leave an extraneous SSH session open throughout the life of the connection.

I am not philosophically opposed to allowing ExtSSH with the Session Manager, but I would need to address the issue of the extraneous SSH session. I first need to understand the use case that necessitates using ExtSSH with the Session Manager, since that was not intended to be a supported workflow in TurboVNC 3.0. I also think it would probably be best to allow that option only if SessMgrAuto is disabled. (The design principle of the Session Manager is to be "secure by default" and prevent users from overriding any security-related settings unless SessMgrAuto is disabled.)

[Parakleta]

I don’t think it can leave the other connection open because I don’t get an error opening the required ports with the external ssh program. I’d have to check that though to confirm.

My use case is that I open additional port forwarding, specifically to socket files on the server which can have access controls applied to them.

ETA: Actually I guess the session could be left open so long as it hasn’t tried to set up a tunnel yet.

[dcommander]

Yes, it is effectively the same as if you had opened a separate SSH session in another window. Port forwarding is only enabled for the viewer SSH session, not the Session Manager SSH session. (When using the built-in SSH client, the two sessions are the same.)

I will go ahead and fix the issue. Just understand that using ExtSSH with the Session Manager isn't officially supported yet, and without public key authentication, that configuration will require that you authenticate twice. (Officially supporting ExtSSH with the Session Manager will require using the OpenSSH ControlMaster option to enable reuse of the SSH session when using an external SSH client.)