Ubuntu – Connecting with vinagre (VNC) through intermediary ssh server

In case we connect to a remote X-Server via VNC we have the advantage that the graphical application will stay running even when the SSH connection to the remote is down. We can then reconnect to resume the graphical application. See also:

• Differences between VNC and ssh -X

To speed up reconnection we may combine the connection to the remote with an SSH session by using vncviewer from tightvncviewer with the option -via. By this we can run on the remote server:

vncserver:0  ## or any other display number e.g. :1

to establish a connection on the viewer via an SSH tunnel:

vncviewer -via user@remote localhost:0

Doing so will need considerably more bandwith because the whole desktop will have to be transmitted from the VNC server. Therefore it may not really be a good idea for low bandwith connections but it may give you a somewhat better experience on high bandwith but unstable connections as compared with X-forwarding.

If the active virtual terminal is different from that one the X server runs at (e.g. what seems to be your case: You are testing from the same computer, but your vnc viewer runs in a session on another VT than the X server you want to connect to) it does not work. (I just had similar problems, not able to VT-switch anymore but wanting to get to interact with my running X session.)

It is explained there: http://www.karlrunge.com/x11vnc/faq.html#faq-linuxvc. Quote:

Q-108: I use Linux Virtual Terminals (VT's) to implement 'Fast User Switching' between users' sessions (e.g. Betty is on Ctrl-Alt-F7, Bobby is on Ctrl-Alt-F8, and Sid is on Ctrl-Alt-F1: they use those keystrokes to switch between their sessions.) How come the view in a VNC viewer connecting to x11vnc is either completely black, doesn't update, or pixels messed up unless the X session x11vnc is attached to is in the active VT?

This seems to have to do with how applications (the X server processes in this case) must "play nicely" if they are not on the active VT (sometimes called VC for virtual console.) That is, they should not read from the keyboard or mouse or manage the video display unless they have the active VT. Given that it appears the XGetImage() call must ultimately retrieve the framebuffer data from the video hardware itself, it would make sense x11vnc's polling wouldn't work unless the X session had active control of the VT.

There does not seem to be an easy way to work around this. Even xwd(1) doesn't work in this case (try it.) Something would need to be done at a lower level, say in the XFree86/Xorg X server. Also, using the Shadow Framebuffer (a copy of the video framebuffer is kept in main memory) does not appear to fix the problem (last checked 2007.)

If no one is sitting at the workstation and you just want to remotely switch the VT over to the one associated with your X session (so x11vnc can poll it correctly), one can use the chvt(1) command, e.g. "chvt 7" for VT #7.