The problem#

For various reasons you might want graphical access to another computer, since some things can't be done over a text interface, including actually designing and troubleshooting what the graphical interface looks like. The other computer might be in a remote location across the internet, in a different room, or simply have a less convenient form factor like a tablet or television, so it's easier to use your desktop's keyboard, mouse, and monitor.

The solution#

The standard solution for this is VNC, specifically the x11vnc VNC server.

To keep a VNC server open to the current X11 session:

x11vnc -usepw -nevershared -forever -localhost -loop &
#... (run one or more graphical applications that block)
# When done, kill everything.
rkill $$

Then to connect to it, assuming the hostname is tablet and you're set up to connect to it via SSH:

$ vncviewer -via tablet -passwd ~/.vnc/tab-passwd localhost

This assumes you've created a ~/.vnc/passwd password file on the server by running

$ x11vnc -storepasswd

and entering something at the prompt from your favorite password generator. No need to save the password anywhere as the file itself is the actual password; just copy it to the client at ~/.vnc/tab-passwd to match the path used in the example above.

The details#

Loop to keep x11vnc alive#

The -loop option is documented as creating an outer loop that continually reruns x11vnc if it crashes. I had originally written the following shell loop which I think effectively does the same thing:

(
while true
do
    x11vnc -usepw -nevershared -forever -localhost
done
) &

I can't actually test that -loop works the same because I now can't figure out what was causing x11vnc to crash that caused me to write that loop in the first place.

Note the -forever option does something different: it means that the server should stay up even after a client has connected and disconnected.

Use standard input/output instead#

There's instructions in the documentation on using the -inetd flag to directly forward the connection through an SSH connection using only pipes and no sockets, taking advantage of ssvncviewer's support for connecting to various endpoints, not just TCP sockets. Unfortunately, I can't get the example to actually work, although it does work if I leave out the SSH and just connect locally:

$ ssvncviewer exec="x11vnc -inetd -o log.txt -display :0"

Needless to say, a VNC connection with the client and server being the same X11 session is not very useful, but it does confirm that the issue was with the SSH part.

Use Unix sockets instead#

Not sure what was going wrong, but as a workaround, we can just use socat and Unix sockets as discussed in my previous post:

# On the server:
$ socat EXEC:"'x11vnc -inetd -o log.txt -display :0'" \
        UNIX-LISTEN:vnc.sock

# On the client:
$ ssh -N -L ./tablet-vnc.sock:./vnc.sock tablet &
$ ssvncviewer tablet-vnc.sock

This has the advantage of not opening a TCP socket visible to any other users on the server, so we can just not bother with the VNC password file, as the connection is secured by Unix permissions and SSH. It additionally has the advantage over the plain pipes solution that we can grant a different user access to the Unix socket, so the SSH tunnel and VNC server don't have to be owned by the same user.

Why is my keyboard acting weird now?#

If you were running x11vnc on your machine and now holding down a key no longer causes it to repeat, so, for instance, you can't hold down Backspace to delete multiple characters, then run

xset r on

The reason is that x11vnc disables that feature because it can result in accidentally repeated keys and it works better for the client to handle the key repeating if desired.