❗ The project currently is unmaintained and is looking for a new maintainer, please see https://github.com/LibVNC/x11vnc/issues/186 ❗

This is x11vnc with its development continued by LibVNC and the GitHub community. While 0.9.13 was the last release by the original author Karl Runge, 0.9.14 was the first community-based release here on GitHub.

This repo represents the x11vnc codebase that once resided in the LibVNCServer repo. It was split off LibVNCServer and moved here with https://github.com/LibVNC/libvncserver/commit/498d222976975f53dea885cfe43ef0f805abd412.

x11vnc: a VNC server for real X displays

x11vnc allows one to view remotely and interact with real X displays (i.e. a display corresponding to a physical monitor, keyboard, and mouse) with any VNC viewer. In this way it plays the role for Unix/X11 that WinVNC plays for Windows.

It has built-in SSL/TLS encryption and 2048 bit RSA authentication, including VeNCrypt support; UNIX account and password login support; server-side scaling; single port HTTPS/HTTP+VNC; Zeroconf service advertising; and TightVNC and UltraVNC file-transfer. It has also been extended to work with non-X devices: natively on Mac OS X Aqua/Quartz, webcams and TV tuner capture devices, and embedded Linux systems such as Qtopia Core. Full IPv6 support is provided. More features are described here.

It also provides an encrypted Terminal Services mode (-create, -svc, or -xdmsvc options) based on Unix usernames and Unix passwords where the user does not need to memorize his VNC display/port number. Normally a virtual X session (Xvfb) is created for each user, but it also works with X sessions on physical hardware. See the tsvnc terminal services mode of the SSVNC viewer for one way to take advantage of this mode.

I wrote x11vnc back in 2002 because x0rfbserver was basically impossible to build on Solaris and had poor performance. The primary x0rfbserver build problems centered around esoteric C++ toolkits. x11vnc is written in plain C and needs only standard libraries and so should work on nearly all Unixes, even very old ones. I also created enhancements to improve the interactive response, added many features, and etc.

This page including the FAQ contains much information [*]; solutions to many problems; and interesting applications, but nevertheless please feel free to contact me if you have problems or questions (and if I save you time or expense by giving you some of my time, please consider a PayPal Donation.) Do check the FAQ and this page first; I realize the pages are massive, but you can often use your browser's find-in-page search action using a keyword to find the answer to your problem or question.

SSVNC: An x11vnc side-project provides an Enhanced TightVNC Viewer package (SSVNC) for Unix, Windows, and Mac OS X with automatic SSL and/or SSH tunnelling support, SSL Certificate creation, Saved connection profiles, Zeroconf, VeNCrypt, and built-in Proxy support. Added features for the TightVNC Unix viewer: NewFBSize, ZRLE encoding, Viewer-side Scaling, cursor alphablending, low color modes, and enhanced popup menu; UltraVNC extensions support for: File Transfer, Text Chat, Single Window, Server Input, and 1/n Scaling extensions, and UltraVNC DSM encryption. The SSVNC bundle could be placed on, say, a USB memory stick for SSL/SSH VNC viewing from nearly any networked computer.

Announcements

Important: If you created any permanent SSL certificates (e.g. via "x11vnc -ssl SAVE ...") on a Debian or Ubuntu system from Sept. 2006 through May 2008, then those keys are likely extremely weak and can be easily cracked. The certificate files should be deleted and recreated on a non-Debian system or an updated one. See http://www.debian.org/security/2008/dsa-1571 for details. The same applies to SSH keys (not used by x11vnc directly, but many people use SSH tunnels for VNC access.)

News

See NEWS

Frequently Asked Questions (FAQs)

See FAQ.md

Background

VNC (Virtual Network Computing) is a very useful network graphics protocol (applications running on one computer but displaying their windows on another) in the spirit of X, however, unlike X, the viewing-end is very simple and maintains no state. It is a remote framebuffer (RFB) protocol.

Some VNC links:

For Unix, the traditional VNC implementation includes a "virtual" X11 server Xvnc (usually launched via the vncserver command) that is not associated with a physical display, but provides a "fake" one X11 clients (xterm, firefox, etc.) can attach to. A remote user then connects to Xvnc via the VNC client vncviewer from anywhere on the network to view and interact with the whole virtual X11 desktop.

The VNC protocol is in most cases better suited for remote connections with low bandwidth and high latency than is the X11 protocol because it involves far fewer "roundtrips" (an exception is the cached pixmap data on the viewing-end provided by X.) Also, with no state maintained the viewing-end can crash, be rebooted, or relocated and the applications and desktop continue running. Not so with X11.

So the standard Xvnc/vncserver program is very useful, I use it for things like:

Desktop conferencing with other users (e.g. code reviews.)
Long running apps/tasks I want to be able to view from many places (e.g. from home and work.)
Motif, GNOME, and similar applications that would yield very poor performance over a high latency link.

However, sometimes one wants to connect to a real X11 display (i.e. one attached to a physical monitor, keyboard, and mouse: a Workstation or a SunRay session) from far away. Maybe you want to close down an application cleanly rather than using kill, or want to work a bit in an already running application, or would like to help a distant colleague solve a problem with their desktop, or would just like to work out on the deck for a while. This is where x11vnc is useful.

How to use x11vnc

In this basic example let's assume the remote machine with the X display you wish to view is "far-away.east:0" and the workstation you are presently working at is "sitting-here.west".

Step 0. Download x11vnc (see below) and have it available to run on far-away.east (on some linux distros it is as easy as "apt-get install x11vnc", "emerge x11vnc", etc.) Similarly, have a VNC viewer (e.g. vncviewer) ready to run on sitting-here.west. We recommend TightVNC Viewers (see also our SSVNC viewer.)

Step 1. By some means log in to far-away.east and get a command shell running there. You can use ssh, or even rlogin, telnet, or any other method to do this. We do this because the x11vnc process needs to be run on the same machine the X server process is running on (otherwise things would be extremely slow.)

Step 2. In that far-away.east shell (with command prompt "far-away>" in this example) run x11vnc directed at the far-away.east X session display:

far-away> x11vnc -display :0

You could have also set the environment variable DISPLAY=:0 instead of using "-display :0". This step attaches x11vnc to the far-away.east:0 X display (i.e. no viewer clients yet.)

Common Gotcha: To get X11 permissions right, you may also need to set the XAUTHORITY environment variable (or use the -auth option) to point to the correct MIT-MAGIC-COOKIE file (e.g. /home/joe/.Xauthority.) If x11vnc does not have the authority to connect to the display it exits immediately. More on how to fix this below.

If you suspect an X11 permissions problem do this simple test: while sitting at the physical X display open a terminal window (gnome-terminal, xterm, etc.) You should be able to run x11vnc successfully in that terminal without any need for command line options. If that works OK then you know X11 permissions are the only thing preventing it from working when you try to start x11vnc via a remote shell. Then fix this with the tips below.

Note as of Feb/2007 you can also try the -find option instead of "-display ..." and see if that finds your display and Xauthority. Note as of Dec/2009 the -findauth and "-auth guess" options may be helpful as well. (End of Common Gotcha)

When x11vnc starts up there will then be much chatter printed out (use "-q" to quiet it), until it finally says something like:

.
.
13/05/2004 14:59:54 Autoprobing selected port 5900
13/05/2004 14:59:54 screen setup finished.
13/05/2004 14:59:54
13/05/2004 14:59:54 The VNC desktop is far-away:0
PORT=5900

which means all is OK, and we are ready for the final step.

Step 3. At the place where you are sitting (sitting-here.west in this example) you now want to run a VNC viewer program. There are VNC viewers for Unix, Windows, MacOS, Java-enabled web browsers, and even for PDA's like the Palm Pilot and Cell Phones! You can use any of them to connect to x11vnc (see the above VNC links under "Background:" on how to obtain a viewer for your platform or see this FAQ. For Solaris, vncviewer is available in the Companion CD package SFWvnc.)

In this example we'll use the Unix vncviewer program on sitting-here by typing the following command in a second terminal window:

sitting-here> vncviewer far-away.east:0

That should pop up a viewer window on sitting-here.west showing and allowing interaction with the far-away.east:0 X11 desktop. Pretty nifty! When finished, exit the viewer: the remote x11vnc process will shutdown automatically (or you can use the -forever option to have it wait for additional viewer connections.)

Common Gotcha: Nowadays there will likely be a host-level firewall on the x11vnc side that is blocking remote access to the VNC port (e.g. 5900.) You will either have to open up that port (or a range of ports) in your firewall administration tool, or try the SSH tunnelling method below (even still the firewall must allow in the SSH port, 22.)

Shortcut: Of course if you left x11vnc running on far-away.east:0 in a terminal window with the -forever option or as a service, you'd only have to do Step 3 as you moved around. Be sure to use a VNC Password or other measures if you do that.

Super Shortcut: Here is a potentially very easy way to get all of it working.

Have x11vnc (0.9.3 or later) available to run on the remote host (i.e. in $PATH.)
Download and unpack a SSVNC bundle (1.0.19 or later, e.g. ssvnc_no_windows-1.0.28.tar.gz) on the Viewer-side machine.
Start the SSVNC Terminal Services mode GUI: ./ssvnc/bin/tsvnc
Enter your remote username@hostname (e.g. fred@far-away.east) in the "VNC Terminal Server" entry.
Click "Connect".

That will do an SSH to username@hostname and start up x11vnc and then connect a VNC Viewer through the SSH encrypted tunnel.

There are a number of things assumed here, first that you are able to SSH into the remote host; i.e. that you have a Unix account there and the SSH server is running. On Unix and MacOS X it is assumed that the ssh client command is available on the local machine (on Windows a plink binary is included in the SSVNC bundle.) Finally, it is assumed that you are already logged into an X session on the remote machine, e.g. your workstation (otherwise, a virtual X server, e.g. Xvfb, will be started for you.)

In some cases the remote SSH server will not run commands with the same $PATH that you normally have in your shell there. In this case click on Options -> Advanced -> X11VNC Options, and type in the location of the x11vnc binary under "Full Path". (End of Super Shortcut)

Desktop Sharing: The above more or less assumed nobody was sitting at the workstation display "far-away.east:0". This is often the case: a user wants to access her workstation remotely. Another usage pattern has the user sitting at "far-away.east:0" and invites one or more other people to view and interact with his desktop. Perhaps the user gives a demo or presentation this way (using the telephone for vocal communication.) A "Remote Help Desk" mode would be similar: a technician connects remotely to the user's desktop to interactively solve a problem the user is having.

For these cases it should be obvious how it is done. The above steps will work, but more easily the user sitting at far-away.east:0 simply starts up x11vnc from a terminal window, after which the guests would start their VNC viewers. For this usage mode the "-connect host1,host2" option may be of use to automatically connect to the vncviewers in "-listen" mode on the list of hosts.

Tunnelling x11vnc via SSH

The above example had no security or privacy at all. When logging into remote machines (certainly when going over the internet) it is best to use ssh, or use a VPN (for a VPN, Virtual Private Network, the above example should be pretty safe.)

For x11vnc one can tunnel the VNC protocol through an encrypted ssh channel. It would look something like running the following commands:

sitting-here> ssh -t -L 5900:localhost:5900 far-away.east 'x11vnc -localhost -display :0'

(you will likely have to provide passwords/passphrases to login from sitting-here into your far-away.east Unix account; we assume you have a login account on far-away.east and it is running the SSH server)

And then in another terminal window on sitting-here run the command:

sitting-here> vncviewer -encodings "copyrect tight zrle hextile" localhost:0

Note: The -encodings option is very important: vncviewer will often default to "raw" encoding if it thinks the connection is to the local machine, and so vncviewer gets tricked this way by the ssh redirection. "raw" encoding will be extremely slow over a networked link, so you need to force the issue with -encodings "copyrect tight ...". Nowadays, not all viewers use the -encodings option, try "-PreferredEncoding=ZRLE" (although the newer viewers seem to autodetect well when to use raw or not.)

Note that "x11vnc -localhost ..." limits incoming vncviewer connections to only those from the same machine. This is very natural for ssh tunnelling (the redirection appears to come from the same machine.) Use of a VNC password is also strongly recommended.

Note also the -t we used above (force allocate pseudoterminal), it actually seems to improve interactive typing response via VNC!

You may want to add the -C option to ssh to enable compression. The VNC compression is not perfect, and so this may help a bit. However, over a fast LAN you probably don't want to enable SSH compression because it can slow things down. Try both and see which is faster.

If your username is different on the remote machine use something like: "fred@far-away.east" in the above ssh command line.

Some VNC viewers will do the ssh tunnelling for you automatically, the TightVNC Unix vncviewer does this when the "-via far-away.east" option is supplied to it (this requires x11vnc to be already running on far-away.east or having it started by inetd(8).) See the 3rd script example below for more info.

SSVNC: You may also want to look at the Enhanced TightVNC Viewer (ssvnc) bundles because they contain scripts and GUIs to automatically set up SSH tunnels (e.g. the GUI, "ssvnc", does it automatically and so does this command: "ssvnc_cmd -ssh user@far-away.east:0") and can even start up x11vnc as well.

The Terminal Services mode of SSVNC is perhaps the easiest way to