How to jump hosts using vglconnect

[ashleyabraham]

I am using Windows 10, installed Cygwin and VirtualGL client successfully. I am trying to connect to a Server (B) which has VirtualGL installed it and it is only accessible from Server (A), which doesn't have VirtualGL installaed in it. The X11 forwarding works as it should when I use SSH -X -Y. How do I connect to Server B via Server A using vglconnect and have all the 3D/GL rendered/forwarded properly? Appreciate any help. Thanks

[dcommander]

https://cdn.rawgit.com/VirtualGL/virtualgl/2.6.3/doc/index.html#hd008002

[ashleyabraham]

The gateway server doesn't have VirtualGL Client and I don't have control of/access to it other than tunneling through it, is there a way to tunnel through without having to connect via vglconnect?

[dcommander]

Can you post an example of the commands that you would normally use to tunnel through the gateway?

[dcommander]

NOTE: the SSH gateway doesn't actually need the VirtualGL Client. Here's what is occurring behind the scenes:

From the client machine, vglconnect -s:

1. launches the VirtualGL Client on the client machine, if it isn't already launched
2. opens a preliminary SSH connection to the SSH gateway and invokes /opt/VirtualGL/bin/nettest -findport to find an available inbound TCP port on the SSH gateway
3. opens a final SSH connection to the SSH gateway and sets up SSH port forwarding so that the available port on the SSH gateway is forwarded to the VirtualGL Client's listening port (usually 4242) on the client machine
4. invokes /opt/VirtualGL/bin/vgllogin -s {port} on the SSH gateway, where {port} is the available port obtained in Step 2 above. This sets the VGL_CLIENT environment variable to localhost and the VGL_PORT environment variable to {port}, thus redirecting VGL Transport traffic through the forwarded SSH port and to the client machine. This also sets the special environment variable __VGL_SSHTUNNEL to 1.

From the SSH gateway, vglconnect -s:

1. detects that VGL_PORT and __VGL_SSHTUNNEL are already set and thus does not launch the VirtualGL Client
2. opens a preliminary SSH connection to the VirtualGL server and invokes /opt/VirtualGL/bin/nettest -findport to find an available inbound TCP port on the VirtualGL server
3. opens a final SSH connection to the VirtualGL server and sets up SSH port forwarding so that the available port on the VirtualGL server is forwarded to the available port on the SSH gateway
4. invokes /opt/VirtualGL/bin/vgllogin -s {port} on the VirtualGL server, where {port} is the available port obtained in Step 2 above. This sets the VGL_CLIENT environment variable to localhost and the VGL_PORT environment variable to {port}, thus redirecting VGL Transport traffic through the forwarded SSH port and to the SSH gateway, which is already redirecting VGL Transport traffic to the client machine. This also sets the special environment variable __VGL_SSHTUNNEL to 1.

If you have an interactive shell on the SSH gateway, then you can simply copy the vglconnect and vgllogin scripts and the nettest executable to your home directory on the SSH gateway, and specify the directory under which they are installed by passing -bindir {dir} to vglconnect on the client machine (e.g. vglconnect -s -bindir /home/user1/vgl/.) If you don't have an interactive shell on the SSH gateway, then you'll have to clue me in as to how you normally establish bi-level SSH tunnels through that gateway. Or you'll have to figure out how to set up bi-level VGL Transport forwarding properly using the nuts-and-bolts information I provided above.

[someuser12]

I think a short answer to @ashleyabraham's question might be the following: first open on the local machine a tunnel from a local port (say, 12345) to port 22 of Server B through Server A:

local$ ssh -f -N -L 12345:serverb.com:22 servera.com

then use vglconnect on the local machine to connect to Server B through the tunnel:

local$ vglconnect -s localhost -p 12345

This doesn't require a VirtualGL client or even the nettest executable or a script to be installed on Server A.

[dcommander]

@someuser12 The shorter answer is that you don't need to do anything except use vglconnect -s on both the client and the gateway. I merely provided the long-winded answer above to describe why that works. The fact that it works is already stated in the User's Guide: https://rawcdn.githack.com/VirtualGL/virtualgl/3.0.2/doc/index.html#hd008002.

[someuser12]

First of all, thanks a lot for providing VirtualGL!

Unfortunetaly, using vglconnect -s on the gateway fails if no VirtualGL client is installed on it and you can't install one.

At least in my case, the approach above (with an SSH tunnel) was helpful and much easier than to copy the vglconnect and vgllogin scripts and the nettest executable to my home directory on the SSH gateway (I'm not sure the nettest executable is compatible across all versions of Linux, let alone Mac OS). I wrote it because it might be useful for other gateways.

[dcommander]

@someuser12 I don't know why vglconnect would fail in a multi-level tunnel. As you can see from the vglconnect source code, it does not look for or invoke vglclient if __VGL_SSHTUNNEL is 1 and VGL_PORT is set, which should be the case if you connected using vglconnect -s.

[someuser12]

In my case, that's because no VirtualGL client is installed on the gateway (Server A), and when I try vglconnect -s servera.com, it fails with ERROR: The server does not appear to have VirtualGL 2.1 or later. This is why I used first a SSH tunnel to Server B through Server A.

[dcommander]

@someuser12 That error just means that vglconnect can't find nettest on the server. It looks under /opt/VirtualGL/bin by default, but per my comment above, you can pass -b {dir} to vglconnect to have it look for nettest in a different directory on the server, such as a directory under your home directory.