More Single Click x11vnc tricks

Here are some additional tips and tricks for doing 'Single Click' type connections with x11vnc.

Using an x11vnc Helpdesk password:

One could hardwire a password into the download script. This relies on obscurity i.e. no bad people know about your "hd/vnc" script on the web, only the Unix user seeking help. This could be pretty safe if there are no web links to the directory and you tell the user the URL over the phone (email is more convenient, but could be sniffed probably more easily than sniffing the downloading of the script).

The script would then look like this:

#!/bin/sh

password="oompa"

webhost="http://www.mysite.com/hd"  # Your helpdesk dir URL.

vnchost="ip.someplace.net"          # Your host running 'vncviewer -listen' 
                                    # It could also be your IP number. If it is
                                    # a router/firewall, you will need to 
                                    # configure it to redirect port 5500 to your
                                    # workstation running 'vncviewer -listen'

dir=/tmp/vnc_helpdesk.$$            # Make a temporary working dir.
mkdir $dir || exit 1
cd $dir || exit 1

trap "cd /tmp; rm -rf $dir" 0 2 15  # Cleans up on exit.

wget $webhost/x11vnc                # Fetch x11vnc binary.  If multi-
chmod 755 ./x11vnc                  # platform, use $webhost/`uname`/x11vnc
                                    # or similar.

./x11vnc -connect_or_exit $vnchost -rfbport 0 -passwd "$password"

Then you, the helpdesk operator, will need to supply this password when your viewer becomes attached to the remote x11vnc. The password could be changed on a per-user basis if desired.

If you want to use -rfbauth instead of -passwd you will have to do an extra wget for the rfbauth file as well (because it is not ASCII). This is probably not worth the trouble unless there are untrusted local users on the naive User's side.

A better way would be to prompt the user for a password you told her by some other means, say over the phone or via email:

#!/bin/sh

printf "Enter the agreed upon helpdesk password: "
password=`head -n 1 /dev/tty`
echo
echo "Using \"$password\""

webhost="http://www.mysite.com/hd"  # Your helpdesk dir URL.

vnchost="ip.someplace.net"          # Your host running 'vncviewer -listen' 
                                    # It could also be your IP number. If it is
                                    # a router/firewall, you will need to 
                                    # configure it to redirect port 5500 to your
                                    # workstation running 'vncviewer -listen'

dir=/tmp/vnc_helpdesk.$$            # Make a temporary working dir.
mkdir $dir || exit 1
cd $dir || exit 1

trap "cd /tmp; rm -rf $dir" 0 2 15  # Cleans up on exit.

wget $webhost/x11vnc                # Fetch x11vnc binary.  If multi-
chmod 755 ./x11vnc                  # platform, use $webhost/`uname`/x11vnc
                                    # or similar.

./x11vnc -connect_or_exit $vnchost -rfbport 0 -passwd "$password"

A Desktop GUI prompt would be possible too, but would require xmessage(1), or some other little tool. That is left as an exercise for the reader.

Using an x11vnc Helpdesk SSL Certificate:

One can hardwire a public SSL certificate or a URL to one into the download script.

This doesn't rely on obscurity so much since only you (the helpdesk operator) will have the corresponding private key part.

In the "hd" web directory suppose you create a file "ssl.crt" that might look something like this:

(we show how to make these below).

Then modify the "vncs" script to download it and use the -sslverify x11vnc option:

#!/bin/sh

webhost="http://www.mysite.com/hd"  # Your helpdesk dir URL.

vnchost="ip.someplace.net"          # Your host running 'vncviewer -listen' 
                                    # It could also be your IP number. If it is
                                    # a router/firewall, you will need to 
                                    # configure it to redirect port 5500 to your
                                    # workstation running 'vncviewer -listen'

dir=/tmp/vnc_helpdesk.$$            # Make a temporary working dir.
mkdir $dir || exit 1
cd $dir || exit 1

trap "cd /tmp; rm -rf $dir" 0 2 15  # Cleans up on exit.

wget $webhost/x11vnc                # Fetch x11vnc binary.  If multi-
chmod 755 ./x11vnc                  # platform, use $webhost/`uname`/x11vnc
                                    # or similar.

wget $webhost/ssl.crt               # Fetch the helpdesk SSL Cert.

./x11vnc -connect_or_exit $vnchost -rfbport 0 -sslverify ./ssl.crt -ssl

Now you, the helpdesk operator, will need to supply the corresponding private key to your STUNNEL on the viewer side, otherwise x11vnc won't let you connect.

Your file, suppose it is called "mycert.pem" might look something like this:

If you are using SSVNC as the listening VNC viewer, click on 'Certs ...' and then 'Browse' for 'MyCert' and maneuver to and select your mycert.pem file. Then set SSVNC to Listen mode and then click 'Listen'. You will still need to UN-select 'Verify All Certs'; see the next section on how to have a User-side cert in addition to this Helpdesk-side cert.

On the other hand if you are using STUNNEL manually instead of SSVNC, modify your stunnel.cfg config file to look like:

foreground = yes
pid =
cert = /path/to/my/mycert.pem

[vnc]
accept = 5500
connect = localhost:5501

run "stunnel stunnel.cfg and remember to use have your viewer listen like this: "vncviewer -listen 1" (i.e. 1 to correspond to the 5501 port).

How to make the SSL Certificate and Private Key?

An easy way is to run x11vnc like this:

  x11vnc -ssl SAVE -rawfb rand

then answer "n" (no) to the "Protect key with a passphrase?" prompt. Then after x11vnc starts listening kill it with Ctrl-C.

You will then have the two files:

   ~/.vnc/certs/server.crt
   ~/.vnc/certs/server.pem

The first one will (SSL cert) be the "ssl.crt" that goes to the user, and the second one (SSL cert + private key) is the "mycert.pem" one you keep locally and use as above. You can move them somewhere else and then delete those created directories if you like.

A more formal, but drawn out, way to use x11vnc would be like this:

   mkdir ./my_ssl
   x11vnc -ssldir ./my_ssl -sslGenCA
   x11vnc -ssldir ./my_ssl -sslGenCert server self:helpdesk

For the 2nd and 3rd commands you will need to answer some prompts. Put in whatever information you care to, or go with the defaults. For the 3rd command be sure to answer "n" (no) to the "Protect key with a passphrase?" prompt. The 2nd command (CA creation) will require supplying a passphrase, just make up any one; it won't be used because we use the "self:" keyword in "self:helpdesk" in the 3rd command (apologies for the inconvenience...).

After those 3 command you will have these two cert files:

   ./my_ssl/server-self:helpdesk.crt
   ./my_ssl/server-self:helpdesk.pem

"server-self:helpdesk.crt" is cert only and goes to user, i.e. "ssl.crt" above; and "server-self:helpdesk.pem" corresponds to "mycert.pem" above. You can copy them elsewhere and then remove the my_ssl directory if you like.

You can find more info about SSL certs here (both using x11vnc's convenience methods and other ways).

Achilles Heel: Please remember there is a big potential hole in all of this Helpdesk stuff if the bad guy can alter what the naive user downloads via wget. How easy this would be is not clear, but it is possible and we do not guard against it. One would supposedly have to use HTTPS SSL certificates signed by CA to protect the initial download (it is not clear the naive User would notice something fishy going on with this part; they would probably just click "OK"). There is a lot of work to make this Helpdesk operation incredibly secure, but it is not too much trouble to have it be "pretty good". We leave it up to you how much to implement.

Using an x11vnc Helpdesk SSL Certificate to authenticate the User:

The above SSL Certificate method only authenticates the HelpDesk viewer (you, with a VNC Viewer) to the naive User (x11vnc side).

This is pretty good, the user can be confident that the Helpdesk viewer is you (however see Achilles Heel above), but it means a bad person who knows about the http://www.mysite.com/hd/vncs script can also connect his desktop to your VNC Viewer. Exactly what harm he could do by this is not clear, but perhaps he would trick you into typing a root password into his desktop.

Plugging this hole is a bit tricky, especially considering the user is naive. We have to give the user a SSL Cert + private key and use the SSL Cert part on our side to authenticate the user. We could hard-wire it into the script (or a URL that points to it), but that defeats the purpose because it is assumed the bad guy knows the URL to the script.

So we'd like to send the naive User his SSL Cert + private key by another channel. Email is the only reasonable alternative (there is no way to give it to him over the phone).

Let's assume we mail the SSL Cert + private key named "helpdesk.pem" to the naive Unix User and he is competent enough to save the attachment to his home directory: "$HOME/helpdesk.pem". Another place it might wind up is "$HOME/Desktop/helpdesk.pem" so we check there too:

#!/bin/sh

helpdesk_pem="$HOME/helpdesk.pem"

if [ ! -f $helpdesk_pem ]; then
	helpdesk_pem="$HOME/Desktop/helpdesk.pem"
fi

if [ ! -f $helpdesk_pem ]; then
	echo "Could not find helpdesk.pem in your Home or Desktop Folder"
	echo "Copy it there and try again."
	exit 1
fi

webhost="http://www.mysite.com/hd"  # Your helpdesk dir URL.

vnchost="ip.someplace.net"          # Your host running 'vncviewer -listen' 
                                    # It could also be your IP number. If it is
                                    # a router/firewall, you will need to 
                                    # configure it to redirect port 5500 to your
                                    # workstation running 'vncviewer -listen'

dir=/tmp/vnc_helpdesk.$$            # Make a temporary working dir.
mkdir $dir || exit 1
cd $dir || exit 1

trap "cd /tmp; rm -rf $dir" 0 2 15  # Cleans up on exit.

wget $webhost/x11vnc                # Fetch x11vnc binary.  If multi-
chmod 755 ./x11vnc                  # platform, use $webhost/`uname`/x11vnc
                                    # or similar.

wget $webhost/ssl.crt               # Fetch the helpdesk SSL Cert.

./x11vnc -connect_or_exit $vnchost -rfbport 0 -sslverify ./ssl.crt -ssl "$helpdesk_pem"

Note that this script also does the VNC Viewer authentication with -sslverify as described above.

OK, almost ready. Now you, the helpdesk operator, have the helpdesk.crt SSL cert (no private key like in the .pem) on your side. If you are using SSVNC, click on 'Certs ...' then 'Browse' for 'ServerCert', maneuver to helpdesk.crt and select it. You can and should now leave 'Verify All Certs' selected.

If you are doing a manual STUNNEL instead of SSVNC, here would be your stunnel.cfg (used as shown above).

foreground = yes
pid =
cert = /path/to/my/mycert.pem
CAfile = /path/to/my/helpdesk.crt
verify = 2

[vnc]
accept = 5500
connect = localhost:5501

Let me know if you try any of these tricks out and how they went!

Multiple Unix Platforms:

If you need to support multiple Unix platforms via this scheme (e.g. the Helpdesks gets calls from many different flavors of Unix), perhaps create subdirs hd/Linux.i686, hd/SunOS.sun4u, etc. placing the correct binaries in each and then modify the vnc script to have:

   wget $webhost/`uname -sm | sed -e 's/ /./g'`/x11vnc

to find the OS's binary. Of course you could create .tar.gz or .zip archives of the x11vnc and vnc (the latter modified, i.e. no wget or tmpdir needed) programs that the user downloads, unpacks and runs vnc. Or perhaps you avoid the website completely and just email him the archive with instructions to unpack and run the script.

Note if the user is on MacOSX then he more likely has curl than wget. So you could change everything to use that, e.g.:

curl $webhost/x11vnc > ./x11vnc

etc. Or one could also have vnc test for the the presence of wget or curl, e.g.

if type wget >/dev/null; then
	wget -O - $webhost/x11vnc > ./x11vnc
elif type curl >/dev/null; then
	curl $webhost/x11vnc > ./x11vnc
else
	lynx -source $webhost/x11vnc > ./x11vnc
fi

etc. However note that the user will need to be told to paste in a similar line to the terminal to automatically download and run the "vnc" script.

STUNNEL on the x11vnc side:

As of Apr/2007 x11vnc supports reverse connections in SSL, so SSL Single Click are made easier: you simply add the -ssl option to the x11vnc command line.

However, if your version of x11vnc is too old and you don't want to upgrade, or for some other reason you don't want to use "x11vnc -ssl ...", here is a way using STUNNEL. It requires the user downloading (wget) more from the website.

To do this, include a copy of an stunnel binary that will run on the user's machine (Linux, etc.) in the "hd" directory in addition to the x11vnc binary you have there for the normal way.

Next, create a file named "vncs" containing the following:

#!/bin/sh

webhost="http://www.mysite.com/hd"  # Your helpdesk dir URL.

vnchost="ip.someplace.net"          # Your host running 'vncviewer -listen' 
                                    # It could also be your IP number. If it is
                                    # a router/firewall, you will need to 
                                    # configure it to redirect port 5500 to your
                                    # workstation running 'vncviewer -listen'

dir=/tmp/vnc_helpdesk.$$            # Make a temporary working dir.
mkdir $dir || exit 1
cd $dir || exit 1

trap 'cd /tmp; kill $pid; rm -rf $dir' 0 2 15   # Cleans up on exit.

# One could put these files in a .tar.gz file instead, and "| tar xzvf -"
#
wget $webhost/x11vnc
wget $webhost/stunnel
chmod 755 ./x11vnc ./stunnel

# Make stunnel conf file:
#
cat > ./stunnel.conf <<END
foreground = yes
pid =
client = yes
debug = 6
# One could do SSL cert auth too... need to wget vnchost's public key.
# CAfile = ./cert.pub
# verify = 2

[vnc]
accept = localhost:5500
connect = $vnchost
END

./stunnel ./stunnel.conf &
pid=$!

./x11vnc -connect_or_exit localhost:5500 -rfbport 0 -nopw

with the hostnames or IP addresses customized to your case.

The helpdesk operator would have "vncviewer -listen" running as above, but he also needs an SSL tunnel at his end. See the Single Click FAQ for how to do this with SSVNC or STUNNEL.

In any event, with SSL tunnel having been setup and your viewer listing, the naive user is instructed to paste in and run:

   wget -qO - http://www.mysite.com/hd/vncs | sh -

to pick up the vncs script this time.

With an stunnel scheme like this you could add the helpdesk's public key (see the CAfile line above) to add some more protection by requiring the VNC viewer side to authenticate itself.

OpenSSL libssl.so.0.9.7 problems:

If you build your own stunnel or x11vnc for deployment, you may want to statically link libssl.a and libcrypto.a into it because Linux distros are currently a bit of a mess regarding which version of libssl is installed.

The quickest way to static link is a bit of a kludge: you let the build proceed normally then look at the output for the final link, e.g.:

  ...
  (build output)
  ...
  gcc -g -O2 -Wall -Wshadow -Wcast-align -Wpointer-arith -I/usr/include -o stunnel client.o log.o options.o protocol.o network.o resolver.o ssl.o sthreads.o stunnel.o pty.o -lz -ldl -lutil -lnsl -L/usr/lib -lssl -lcrypto -lwrap

You see that command was run in the src/ subdirectory, and so you cd to it and change the command line so that everywhere you see -lssl you replace it with /usr/lib/libssl.a and -lcrypto you replace it with /usr/lib/libcrypto.a:

  cd src
  gcc -g -O2 -Wall -Wshadow -Wcast-align -Wpointer-arith -I/usr/include -o stunnel client.o log.o options.o protocol.o network.o resolver.o ssl.o sthreads.o stunnel.o pty.o -lz -ldl -lutil -lnsl -L/usr/lib /usr/lib/libssl.a /usr/lib/libcrypto.a -lwrap

Then the resulting stunnel binary does not have a dynamic dependency on libssl.so.0.9.X or libcrypto.so.0.9.X and so should work on many Linux systems. You should do this build on a relatively older, 1-3 years (or the oldest you plan to deploy on), Linux distro (since glibc often adds new spurious dependencies on internal symbols, e.g. __strncpy_chk, even though the application source code is unchanged and does not refer to them).

Perhaps a cleaner way that avoids rerunning a modified link line:

  mkdir /tmp/libs
  cp /usr/lib/libssl.a /usr/lib/libcrypto.a /tmp/libs
  env LDFLAGS=-L/tmp/libs ./configure
  make
  ...

This libssl problem affects x11vnc binary deployment as well. To try to link even more libaries statically into x11vnc (to try to increase the chances for portability of the deployed binary) consider: /usr/X11R6/lib/libXinerama.a, /usr/X11R6/lib/libXfixes.a, /usr/X11R6/lib/libXdamage.a , and /usr/lib/libjpeg.a. Copy them to using the /tmp/libs scheme above. If you want bundle /usr/X11R6/lib/libXrandr.a you will also need include /usr/X11R6/lib/libXrender.a and add -lXrender to the link line.