Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131 Description of problem: RealVNC provides some useful advantages (notably better speed, at least in perception), but from a straight translation from tightvnc we lose some functionality. The biggest one was support for -via, which automatically set up the SSH tunnel for you. Yes, you can still use RealVNC by setting up the tunnel yourself, but I found users much more comfortable with -via. Version-Release number of selected component (if applicable): vnc-4.0-0.beta3.5.1 How reproducible: Always Steps to Reproduce: 1. vncviewer -via gateway internal:1 Actual Results: Syntax error for the new vncviewer Expected Results: Connection to a machine name internal's VNC server, via an ssh tunnel through the machine 'gateway'. Additional info: I'm calling this a bug, not an enhancement request, because it's a loss of functionality as compared to previous releases. It's not a drop in replacement.
Please try 4.0-0.beta3.9, which provides a -via option. It will appear in rawhide in the next few days.
I have tried the latest rawhide version, and it doesn't correctly handle the case of using an intermediate gateway to access the destination machine: In the case of "vncviewer -via gateway internalhost:1", it executed the following ssh command: /usr/bin/ssh -f -L 5598:localhost:5901 gateway sleep 20 where I would have expected it to run: /usr/bin/ssh -f -L 5598:internalhost:5901 gateway sleep 20 (note the use of localhost as opposed to internalhost). At many sites, the user will not have the capability to run a VNC server on the gateway. In the vnc-via patch, the SSH tunnelling setup shouldn't hardcode localhost. The algorithm should be "if a remote host is specified in the VNC server argument, use that hostname, otherwise use localhost".
I think the current patch does the right thing now.
I agree. Things are as on the old VNC, in this respect.