neulab/tldr huggingface dataset:
Looked at another way, if you do not want to use the su(1) method provided by -unixpw (i.e. su_verify()), you can run x11vnc as root and use -unixpw_nis.  Any users with passwords in /etc/shadow can then be authenticated.
In -unixpw_nis mode, under no circumstances is x11vnc's user password verifying function based on su called (i.e. the function su_verify() that runs /bin/su in a pseudoterminal to verify passwords.)  However, if -unixpw_nis is used in conjunction with the -find and -create -display WAIT:... modes then, if x11vnc is running as root, /bin/su may be called externally to run the find or create commands.
-unixpw_cmd cmd
As -unixpw above, however do not use su(1) but rather run the externally supplied command cmd.  The first line of its stdin will be the username and the second line the received password.  If the command exits with status 0 (success) the VNC user will be accepted.  It will be rejected for any other return status.
Dynamic passwords and non-unix passwords, e.g. LDAP, can be implemented this way by providing your own custom helper program. Note that the remote viewer is given 3 tries to enter the correct password, and so the program may be called in a row that many (or more) times.
If a list of allowed users is needed to limit who can log in, use -unixpw [list] in addition to this option.
In FINDDISPLAY and FINDCREATEDISPLAY modes the cmd will also be run with the RFB_UNIXPW_CMD_RUN env. var.  non-empty and set to the corresponding display find/create command.  The first two lines of input are the username and passwd as in the normal case described above.  To support FINDDISPLAY and FINDCREATEDISPLAY, cmd should run the requested command as the user (and most likely refusing to run it if the password is not correct.)  Here is an example script (note it has a hardwired bogus password "abc"!)
#!/bin/sh # Example x11vnc -unixpw_cmd script.  # Read the first two lines of stdin (user and passwd) read user read pass
debug=0 if [ $debug = 1 ]; then echo "user: $user" 1>&2 echo "pass: $pass" 1>&2 env | egrep -i 'rfb|vnc' 1>&2 fi
# Check if the password is valid.  # (A real example would use ldap lookup, etc!)  if [ "X$pass" != "Xabc" ]; then exit 1    # incorrect password fi
if [ "X$RFB_UNIXPW_CMD_RUN" = "X" ]; then exit 0    # correct password else # Run the requested command (finddisplay) if [ $debug = 1 ]; then echo "run: $RFB_UNIXPW_CMD_RUN" 1>&2 fi exec /bin/su - "$user" -c "$RFB_UNIXPW_CMD_RUN" fi
In -unixpw_cmd mode, under no circumstances is x11vnc's user password verifying function based on su called (i.e. the function su_verify() that runs /bin/su in a pseudoterminal to verify passwords.)  It is up to the supplied unixpw_cmd to do user switching if desired and if it has the permissions to do so.
-find
Find the user's display using FINDDISPLAY. This is an alias for "-display WAIT:cmd=FINDDISPLAY".
Note: if a -display occurs later on the command line it will override the -find setting.
For this and the next few options see -display WAIT:...  below for all of the details.
-finddpy
Run the FINDDISPLAY program, print out the found display (if any) and exit.  Output is like: DISPLAY=:0.0 DISPLAY=:0.0,XPID=12345 or DISPLAY=:0.0,VT=7.  XPID is the process ID of the found X server. VT is the Linux virtual terminal of the X server.
-listdpy
Have the FINDDISPLAY program list all of your displays (i.e. all the X displays on the local machine that you have access rights to).  x11vnc then exits.
-findauth [disp]
Apply the -find/-finddpy heuristics to try to guess the XAUTHORITY file for DISPLAY 'disp'.  If 'disp' is not supplied, then the value in the -display on the cmdline is used; failing that $DISPLAY is used; and failing that ":0" is used.  x11vnc then exits.
If nothing is printed out, that means no XAUTHORITY was found for 'disp'; i.e. failure.  If "XAUTHORITY=" is printed out, that means use the default (i.e. do not set XAUTHORITY).  If "XAUTHORITY=/path/to/file" is printed out, then use that file.
XDM/GDM/KDM: if you are running x11vnc as root and want to find the XAUTHORITY before anyone has logged into an X session yet, use: x11vnc -env FD_XDM=1 -findauth ...  (This will also find the XAUTHORITY if a user is already logged into the X session.)  When running as root, FD_XDM=1 will be tried if the initial -findauth fails.
-create
First try to find the user's display using FINDDISPLAY, if that doesn't succeed create an X session via the FINDCREATEDISPLAY method.  This is an alias for "-display WAIT:cmd=FINDCREATEDISPLAY-Xvfb".
Note: if a -display occurs later on the command line it will override the -create setting.
SSH NOTE: for both -find and -create you can (should!)  add the "-localhost" option to force SSH tunnel access.
-xdummy
As in -create, except Xdummy instead of Xvfb.
-xvnc
As in -create, except Xvnc instead of Xvfb.
-xvnc_redirect
As in -create, except Xvnc.redirect instead of Xvfb.
-xdummy_xvfb
Sets WAIT:cmd=FINDCREATEDISPLAY-Xdummy,Xvfb
-create_xsrv str
Sets WAIT:cmd=FINDCREATEDISPLAY-<str>  Can be on cmdline after anything that sets WAIT:.. and other things (e.g. -svc, -xdmsvc) to adjust the X server list.  Example: -svc ... -create_xsrv Xdummy,X
-svc
Terminal services mode based on SSL access.  Alias for -display WAIT:cmd=FINDCREATEDISPLAY-Xvfb -unixpw -users unixpw= -ssl SAVE Also "-service".
Note: if a -display, -unixpw, -users, or -ssl occurs later on the command line it will override the -svc setting.
-svc_xdummy
As -svc except Xdummy instead of Xvfb.
-svc_xvnc
As -svc except Xvnc instead of Xvfb.
-svc_xdummy_xvfb
As -svc with Xdummy,Xvfb.
-xdmsvc
Display manager Terminal services mode based on SSL.  Alias for -display WAIT:cmd=FINDCREATEDISPLAY-Xvfb.xdmcp -unixpw -users unixpw= -ssl SAVE  Also "-xdm_service".
Note: if a -display, -unixpw, -users, or -ssl occurs later on the command line it will override the -xdmsvc setting.
To create a session a user will have to first log in to the -unixpw dialog and then log in again to the XDM/GDM/KDM prompt. Subsequent re-connections will only require the -unixpw password. See the discussion under -display WAIT:... for more details about XDM, etc configuration.
Remember to enable XDMCP in the xdm-config, gdm.conf, or kdmrc configuration file.  See -display WAIT: for more info.
-sshxdmsvc
Display manager Terminal services mode based on SSH.  Alias for -display WAIT:cmd=FINDCREATEDISPLAY-Xvfb.xdmcp -localhost.
The -localhost option constrains connections to come in via a SSH tunnel (which will require a login).  To create a session a user will also have to log into the XDM GDM KDM prompt. Subsequent re- connections will only only require the SSH login.  See the discussion under -display WAIT:... for more details about XDM, etc configuration.
-unixpw_system_greeter
Present a "Press 'Escape' for System Greeter" option to the connecting VNC client in combined -unixpw and xdmcp FINDCREATEDISPLAY modes (e.g. -xdmsvc).
Normally in a -unixpw mode the VNC client must supply a valid username and password to gain access.  However, if -unixpw_system_greeter is supplied AND the FINDCREATEDISPLAY command matches 'xdmcp', then the user has the option to press Escape and then get a XDM/GDM/KDM login/greeter panel instead. They will then supply a username and password directly to the greeter.
Otherwise, in xdmcp FINDCREATEDISPLAY mode the user must supply his username and password TWICE.  First to the initial unixpw login dialog, and second to the subsequent XDM/GDM/KDM greeter. Note that if the user re-connects and supplies his username and password in the unixpw dialog the xdmcp greeter is skipped and he is connected directly to his existing X session.  So the -unixpw_system_greeter option avoids the extra password at X session creation time.
Example:  x11vnc -xdmsvc -unixpw_system_greeter See -unixpw and -display WAIT:... for more info.
The special options after a colon at the end of the username (e.g. user:solid) described under -display WAIT: are also applied in this mode if they are typed in before the user hits Escape.  The username is ignored but the colon options are not.
The default message is 2 lines in a small font, set the env. var. X11VNC_SYSTEM_GREETER1=true for a 1 line message in a larger font.
If the user pressed Escape the FINDCREATEDISPLAY command will be run with the env. var. X11VNC_XDM_ONLY=1.
-redirect port
As in FINDCREATEDISPLAY-Xvnc.redirect mode except redirect immediately (i.e. without X session finding or creation) to a VNC server listening on port. You can also supply host:port to redirect to a different machine.
If 0 <= port < 200 it is taken as a VNC display (5900 is added to get the actual port), if port < 0 then -port is used.
Probably the only reason to use the -redirect option is in conjunction with SSL support, e.g. -ssl SAVE.  This provides an easy way to add SSL encryption to a VNC server that does not support SSL (e.g. Xvnc or vnc.so) In fact, the protocol does not even need to be VNC, and so "-rfbport port1 -ssl SAVE -redirect host:port2" can act as a replacement for stunnel(1).
This mode only allows one redirected connection.  The -forever option does not apply.  Use -inetd or -loop for persistent service.
-display WAIT:...
A special usage mode for the normal -display option.  Useful with -unixpw, but can be used independently of it.  If the display string begins with WAIT: then x11vnc waits until a VNC client connects before opening the X display (or -rawfb device).
This could be useful for delaying opening the display for certain usage modes (say if x11vnc is started at boot time and no X server is running or users logged in yet).
If the string is, e.g. WAIT:0.0 or WAIT:1, i.e. "WAIT" in front of a normal X display, then that indicated display is used.
One can also insert a geometry between colons, e.g. WAIT:1280x1024:... to set the size of the display the VNC client first attaches to since some VNC viewers will not automatically adjust to a new framebuffer size.
A more interesting case is like this:
WAIT:cmd=/usr/local/bin/find_display
in which case the command after "cmd=" is run to dynamically work out the DISPLAY and optionally the XAUTHORITY data.  The first line of the command output must be of the form DISPLAY=<xdisplay>. On Linux if the virtual terminal is known append ",VT=n" to this string and the chvt(1) program will also be run.  Any remaining output is taken as XAUTHORITY data.  It can be either of the form XAUTHORITY=<file> or raw xauthority data for the display. For example;
xauth extract - $DISPLAY"
NOTE: As specified in the previous paragraph, you can supply your own WAIT:cmd=... program or script, BUT there are two very useful *BUILT-IN* ones: FINDDISPLAY (alias -find above) and FINDCREATEDISPLAY (alias -create above.)  Most people use these instead of creating their own script.  Read the following (especially the BUILT-IN modes sections) to see how to configure these two useful builtin -display WAIT: modes.
In the case of -unixpw (and -unixpw_nis only if x11vnc is running as root), then the cmd= command is run as the user who just authenticated via the login and password prompt.
In the case of -unixpw_cmd, the commands will also be run as the logged-in user, as long as the user-supplied helper program supports RFB_UNIXPW_CMD_RUN (see the -unixpw_cmd option.)
Also in the case of -unixpw, the user logging in can place a colon at the end of her username and supply a few options: scale=, scale_cursor= (or sc=), solid (or so), id=, clear_mods (or cm), clear_keys (or ck), clear_all (or ca), repeat, speeds= (or sp=), readtimeout= (or rd=), viewonly (or vo), nodisplay= (or nd=), rotate= (or ro=), or noncache (or nc), all separated by commas if there is more than one.  After the user logs in successfully, these options will be applied to the VNC screen.  For example,
login: fred:scale=3/4,sc=1,repeat Password: ...
login: runge:sp=modem,rd=120,solid
for convenience m/n implies scale= e.g. fred:3/4  If you type and enter your password incorrectly, to retrieve your long "login:" line press the Up arrow once (before typing anything else).
Most of these colon options only apply to the builtin FINDDISPLAY and FINDCREATEDISPLAY modes, but note that they are passed to the extrenal command in the environment as well and so could be used.
In the login panel, press F1 to get a list of the available options that you can add after the username.
Another option is "geom=WxH" or "geom=WxHxD" (or ge=). This only has an effect in FINDCREATEDISPLAY mode when a virtual X server such as Xvfb is going to be created.  It sets the width and height of the new display, and optionally the color depth as well.
You can also supply "gnome", "kde", "twm", "fvwm", "mwm", "dtwm", "wmaker", "xfce", "lxde", "enlightenment", "Xsession", or "failsafe" (same as "xterm") to have the created display use that mode for the user session.
Specify "tag=..." to set the unique FD_TAG desktop session tag described below.  Note: this option will be ignored if the FD_TAG env. var. is already set or if the viewer-side supplied value is not completely composed of alphanumeric or '_' or '-' characters.
User preferences file: Instead of having the user type in geom=WxH,... etc. every time he logs in to find or create his X session, if you set FD_USERPREFS to a string that does not contain the "/" character, then the user's home directory is prepended to that string and if the file exists its first line is read and appended to any options he supplied at the login: prompt.  For example -env FD_USERPREFS=.x11vnc_create and the user put "geom=1600x1200" in his ~/.x11vnc_create file.
To disable the option setting set the environment variable X11VNC_NO_UNIXPW_OPTS=1 before starting x11vnc.  To set any other options, the user can use the gui (x11vnc -gui connect) or the remote control method (x11vnc -R opt:val) during his VNC session.
So we see the combination of -display WAIT:cmd=... and -unixpw allows automatic pairing of an unix authenticated VNC user with his desktop.  This could be very useful on SunRays and also any system where multiple users share a given machine.  The user does not need to remember special ports or passwords set up for his desktop and VNC.
A nice way to use WAIT:cmd=... is out of inetd(8) (it automatically forks a new x11vnc for each user).  You can have the x11vnc inetd spawned process run as, say, root or nobody.  When run as root (for either inetd or display manager), you can also supply the option "-users unixpw=" to have the x11vnc process switch to the user as well.  Note: there will be a 2nd SSL helper process that will not switch, but it is only encoding and decoding the encrypted stream at that point.
BUILT-IN modes:
-- Automatic Finding of User X Sessions --
As a special case, WAIT:cmd=FINDDISPLAY will run a script that works on most Unixes to determine a user's DISPLAY variable and xauthority data (see who(1) ).
NOTE: The option "-find" is an alias for this mode.
To have this default script printed to stdout (e.g. for customization) run with WAIT:cmd=FINDDISPLAY-print To have the script run to print what display it would find use "-finddpy" or WAIT:cmd=FINDDISPLAY-run
The standard script runs xdpyinfo(1) run on potential displays. If your X server(s) have a login greeter that exclusively grabs the Xserver, then xdpyinfo blocks forever and this mode will not work.  See www.karlrunge.com/x11vnc/faq.html#faq-display-manager for how to disable this for dtgreet on Solaris and possibly for other greeters.
In -find/cmd=FINDDISPLAY mode, if you set FD_XDM=1, e.g. 'x11vnc -env FD_XDM=1 -find ...' and x11vnc is running as root (e.g. inetd) then it will try to find the XAUTHORITY file of a running XDM/GDM/KDM login greeter (i.e. no user has logged into an X session yet.)
As another special case, WAIT:cmd=HTTPONCE will allow x11vnc to service one http request and then exit.  This is usually done in -inetd mode to run on, say, port 5800 and allow the Java vncviewer to be downloaded by client web browsers.  For example:
5815 stream tcp nowait root /usr/sbin/tcpd /.../x11vnc \ -inetd -q -http_ssl -prog /.../x11vnc \ -display WAIT:cmd=HTTPONCE
Where /.../x11vnc is the full path to x11vnc.  It is used in the Apache SSL-portal example (see FAQ).
In this mode you can set X11VNC_SKIP_DISPLAY to a comma separated list of displays (e.g. ":0,:1") to ignore in the finding process. The ":" is optional.  Ranges n-m e.g. 0-20 can also be supplied. This string can also be set by the connecting user via "nd=" using "+" instead of ","  If "nd=all" or you set X11VNC_SKIP_DISPLAY=all then all display finding fails as if you set X11VNC_FINDDISPLAY_ALWAYS_FAILS=1 (below.)
On some systems lsof(1) can be very slow.  Set the env. var. FIND_DISPLAY_NO_LSOF=1 to skip using lsof to try to find the Linux VT the X server is running on.  set FIND_DISPLAY_NO_VT_FIND=1 to avoid looking at all.
-- Automatic Creation of User X Sessions --
An interesting option is WAIT:cmd=FINDCREATEDISPLAY that is like FINDDISPLAY in that is uses the same method to find an existing display.  However, if it does not find one it will try to *start* up an X server session for the user.  This is the only time x11vnc tries to actually start up an X server.
NOTE: The option "-create" is an alias for this mode.
It will start looking for an open display number at :20 Override via X11VNC_CREATE_STARTING_DISPLAY_NUMBER=n By default 80 X displays are allowed (i.e. going to :99) Override via X11VNC_CREATE_MAX_DISPLAYS=n
For its heuristics, the create display script sets LC_ALL=C so that command output is uniform.  By default it will try to restore LC_ALL right before starting the user session.  However, if you don't mind it keeping LC_ALL=C set the env. var.: X11VNC_CREATE_LC_ALL_C_OK=1
By default FINDCREATEDISPLAY will try Xvfb and then Xdummy:
The Xdummy wrapper is part of the x11vnc source code (x11vnc/misc/Xdummy)  It should be available in PATH and have run "Xdummy -install" once to create the shared library.  Xdummy only works on Linux.  As of 12/2009 it no longer needs to be run as root, and the default is to not run as root.  In some circumstances permissions may require running it as root, in these cases specify FD_XDUMMY_RUN_AS_ROOT=1, this is the same as supplying -root to the Xdummy cmdline.
Xvfb is available on most platforms and does not require root.
An advantage of Xdummy over Xvfb is that Xdummy supports RANDR dynamic screen resizing.
When x11vnc exits (i.e. user disconnects) the X server session stays running in the background.  The FINDDISPLAY will find it directly next time.  The user must exit the X session in the usual way for it to terminate (or kill the X server process if all else fails).
To troubleshoot the FINDCREATEDISPLAY mechanism, set the following env. var. to an output log file, e.g -env CREATE_DISPLAY_OUTPUT=/tmp/mydebug.txt
So this is a somewhat odd mode for x11vnc in that it will start up and poll virtual X servers!  This can be used from, say, inetd(8) to provide a means of definitely getting a desktop (either real or virtual) on the machine.  E.g. a desktop service:
5900 stream tcp nowait root /usr/sbin/tcpd /.../x11vnc -inetd -q -http -ssl SAVE -unixpw -users unixpw=\ -passwd secret -prog /.../x11vnc \ -display WAIT:cmd=FINDCREATEDISPLAY
Where /.../x11vnc is the full path to x11vnc.
See the -svc/-service option alias above.
If for some reason you do not want x11vnc to ever try to find an existing display set the env. var X11VNC_FINDDISPLAY_ALWAYS_FAILS=1 (also -env ...)  This is the same as setting X11VNC_SKIP_DISPLAY=all or supplying "nd=all" after "username:"
Use WAIT:cmd=FINDCREATEDISPLAY-print to print out the script that is used for this.
You can specify the preferred X server order via e.g., WAIT:cmd=FINDCREATEDISPLAY-Xdummy,Xvfb,X  and/or leave out ones you do not want.  The the case "X" means try to start up a real, hardware X server using xinit(1) or startx(1).  If there is already an X server running the X case may only work on Linux (see startx(1) ).
"Xvnc" will start up a VNC X server (real- or tight-vnc, e.g. use if Xvfb is not available).  "Xsrv" will start up the server program in the variable "FD_XSRV" if it is non-empty. You can make this be a wrapper script if you like (it must handle :N, -geometry, and -depth and other X server options).
You can set the environment variable FD_GEOM (or X11VNC_CREATE_GEOM) to WxH or WxHxD to set the width and height and optionally the color depth of the created display.  You can also set FD_SESS to be the session (short name of the windowmanager: kde, gnome, twm, failsafe, etc.). FD_OPTS contains extra options to pass to the X server. You can also set FD_PROG to be the full path to the session/windowmanager program.
More FD tricks:  FD_CUPS=port or FD_CUPS=host:port will set the cups printing environment.  Similarly for FD_ESD=port or FD_ESD=host:port for esddsp sound redirection.  Set FD_EXTRA to a command to be run a few seconds after the X server starts up.  Set FD_TAG to be a unique name for the session, it is set as an X property, that makes FINDDISPLAY only find sessions with that tag value.
Set FD_XDMCP_IF to the network interface that the display manager is running on; default is 'localhost' but you may need to set it to '::1' on some IPv6 only systems or misconfigured display managers.
If you want the FINDCREATEDISPLAY session to contact an XDMCP login manager (xdm/gdm/kdm) on the same machine, then use "Xvfb.xdmcp" instead of "Xvfb", etc.  The user will have to supply his username and password one more time (but he gets to select his desktop type so that can be useful).  For this to work, you will need to enable localhost XDMCP (udp port 177) for the display manager.  This seems to be:
for gdm in gdm.conf:   Enable=true in section [xdmcp] for kdm in kdmrc:      Enable=true in section [Xdmcp] for xdm in xdm-config: DisplayManager.requestPort: 177
See the shorthand options above "-svc", "-xdmsvc" and "-sshxdmsvc" that specify the above options for some useful cases.
If you set the env. var WAITBG=1 x11vnc will go into the background once listening in wait mode.
Another special mode is FINDCREATEDISPLAY-Xvnc.redirect, (or FINDDISPLAY-Xvnc.redirect).  In this case it will start up Xvnc as above if needed, but instead of polling it in its normal way, it simply does a socket redirection of the connected VNC viewer to the Xvnc.
So in Xvnc.redirect x11vnc does no VNC but merely transfers the data back and forth.  This should be faster then x11vnc's polling method, but not as fast as connecting directly to the Xvnc with the VNC Viewer.  The idea here is to take advantage of x11vnc's display finding/creating scheme, SSL, and perhaps a few others. Most of x11vnc's options do not apply in this mode.
Xvnc.redirect should also work for the vnc.so X server module for the h/w display however it will work only for finding the display and the user must already be logged into the X console.
-vencrypt mode
The VeNCrypt extension to the VNC protocol allows encrypted SSL/TLS connections.  If the -ssl mode is enabled, then VeNCrypt is enabled as well BY DEFAULT (they both use a SSL/TLS tunnel, only the protocol handshake is a little different.)
To control when and how VeNCrypt is used, specify the mode string. If mode is "never", then VeNCrypt is not used.  If mode is "support" (the default) then VeNCrypt is supported.  If mode is "only", then the similar and older ANONTLS protocol is not simultaneously supported.  x11vnc's normal SSL mode (vncs://) will be supported under -ssl unless you set mode to "force".
If mode is prefixed with "nodh:", then Diffie Hellman anonymous key exchange is disabled.  If mode is prefixed with "nox509:", then X509 key exchange is disabled.
To disable all Anonymous Diffie-Hellman access (susceptible to Man-In-The-Middle attack) you will need to supply "-vencrypt nodh:support -anontls never" or "-vencrypt nodh:only"
If mode is prefixed with "newdh:", then new Diffie Hellman parameters are generated for each connection (this can be time consuming: 1-60 secs; see -dhparams below for a faster way) rather than using the fixed values in the program.  Using fixed, publicly known values is not known to be a security problem.  This setting applies to ANONTLS as well.
Long example: -vencrypt newdh:nox509:support
Also, if mode is prefixed with "plain:", then if -unixpw mode is active the VeNCrypt "*Plain" username+passwd method is enabled for Unix logins.  Otherwise in -unixpw mode the normal login panel is provided.
You *MUST* supply the -ssl option for VeNCrypt to be active.  The -vencrypt option only fine-tunes its operation.
-anontls mode
The ANONTLS extension to the VNC protocol allows encrypted SSL/TLS connections.  If the -ssl mode is enabled, then ANONTLS is enabled as well BY DEFAULT (they both use a SSL/TLS tunnel, only the protocol handshake is a little different.)
ANONTLS is an older SSL/TLS mode introduced by vino.
It is referred to as 'TLS' for its registered VNC security-type name, but we use the more descriptive ´ANONTLS' here because it provides only Anonymous Diffie-Hellman encrypted connections, and hence no possibility for certificate authentication.
To control when and how ANONTLS is used, specify the mode string. If mode is "never", then ANONTLS is not used.  If mode is "support" (the default) then ANONTLS is supported.  If mode is "only", then the similar VeNCrypt protocol is not simultaneously supported.  x11vnc's normal SSL mode (vncs://) will be supported under -ssl unless you set mode to "force".
If mode is prefixed with "newdh:", then new Diffie Hellman parameters are generated for each connection (this can be time consuming: 1-60 secs; see -dhparams below for a faster way) rather than using the fixed values in the program.  Using fixed, publicly known values is not known to be a security problem.  This setting applies to VeNCrypt as well.  See the description of "plain:" under -vencrypt.
Long example: -anontls newdh:plain:support
You *MUST* supply the -ssl option for ANONTLS to be active.  The -anontls option only fine-tunes its operation.
-sslonly
Same as: "-vencrypt never -anontls never"  i.e. it disables the VeNCrypt and ANONTLS encryption methods and only allows standard SSL tunneling.  You must also supply the -ssl ... option (see below.)
-dhparams file
For some operations a set of Diffie Hellman parameters (prime and generator) is needed.  If so, use the parameters in file. In particular, the VeNCrypt and ANONTLS anonymous DH mode need them. By default a fixed set is used. If you do not want to do that you can specify "newdh:" to the -vencrypt and -anontls options to generate a new set each session.  If that is too slow for you, use -dhparams file to a set you created manually via "openssl dhparam -out file 1024"
-nossl
Disable the -ssl option (see below). Since -ssl is off by default -nossl would only be used on the commandline to unset any *earlier* -ssl option (or -svc...)
-ssl [pem]
Use the openssl library (www.openssl.org) to provide a built-in encrypted SSL/TLS tunnel between VNC viewers and x11vnc.  This requires libssl support to be compiled into x11vnc at build time. If x11vnc is not built with libssl support it will exit immediately when -ssl is prescribed.  See the -stunnel option below for an alternative.
The VNC Viewer-side needs to support SSL/TLS as well.  See this URL and also the discussion below for ideas on how to enable SSL support for the viewer: http://www.karlrunge.com/x11vnc/faq.html#faq-ssl-tun nel-viewers . x11vnc provides an SSL enabled Java viewer applet in the classes/ssl directory (-http or -httpdir options.)  The SSVNC viewer package supports SSL tunnels too.
If the VNC Viewer supports VeNCrypt or ANONTLS (vino's encryption mode) they are also supported by the -ssl mode (see the -vencrypt and -anontls options for more info; use -sslonly to disable both of them.)
Use "-ssl /path/to/mycert.pem" to specify an SSL certificate file in PEM format to use to identify and provide a key for this server.  See openssl(1) for more info about PEMs and the -sslGenCert and "-ssl SAVE" options below for how to create them.
The connecting VNC viewer SSL tunnel can (at its option) authenticate this server if it has the public key part of the certificate (or a common certificate authority, CA, is a more sophisticated way to verify this server's cert, see -sslGenCA below).  This authentication is done to prevent Man-In-The-Middle attacks.  Otherwise, if the VNC viewer simply accepts this server's key WITHOUT verification, the traffic is protected from passive sniffing on the network, but *NOT* from Man-In-The-Middle attacks. There are hacker tools like dsniff/webmitm and cain that implement SSL Man-In-The-Middle attacks.
If [pem] is empty or the string "SAVE" then the openssl(1) command must be available to generate the certificate the first time.  A self-signed certificate is generated (see -sslGenCA and -sslGenCert for use of a Certificate Authority.)  It will be saved to the file ~/.vnc/certs/server.pem.  On subsequent calls if that file already exists it will be used directly.
Use "SAVE_NOPROMPT" to avoid being prompted to protect the generated key with a passphrase.  However in -inetd and -bg modes there will be no prompting for a passphrase in either case.
If [pem] is "SAVE_PROMPT" the server.pem certificate will be created based on your answers to its prompts for all info such as OrganizationalName, CommonName, etc.
Use "SAVE-<string>" and "SAVE_PROMPT-<string>" to refer to the file ~/.vnc/certs/server-<string>.pem instead (it will be generated if it does not already exist).  E.g. "SAVE-charlie" will store to the file ~/.vnc/certs/server-charlie.pem
Examples: x11vnc -ssl SAVE -display :0 ...  x11vnc -ssl SAVE- someother -display :0 ...
If [pem] is "TMP" and the openssl(1) utility command exists in PATH, then a temporary, self-signed certificate will be generated for this session.  If openssl(1) cannot be used to generate a temporary certificate x11vnc exits immediately.  The temporary cert will be discarded when x11vnc exits.
If successful in using openssl(1) to generate a temporary certificate in "SAVE" or "TMP" creation modes, the public part of it will be displayed to stderr (e.g. one could copy it to the client-side to provide authentication of the server to VNC viewers.)
NOTE: In "TMP" mode, unless you safely copy the public part of the temporary Cert to the viewer for authenticate *every time* (unlikely...), then only passive sniffing attacks are prevented and you are still open to Man-In-The-Middle attacks.  This is why the default "SAVE" mode is preferred (and more sophisticated CA mode too).  Only with saved keys AND the VNC viewer authenticating them (via the public certificate), are Man-In-The-Middle attacks prevented.
If [pem] is "ANON" then the Diffie-Hellman anonymous key exchange method is used.  In this mode there are *no* SSL certificates and so it is not possible to authenticate either the VNC server or VNC client.  Thus only passive network sniffing attacks are avoided: the "ANON" method is susceptible to Man-In-The-Middle attacks. "ANON" is not recommended; instead use a SSL PEM you created or the default "SAVE" method.
See -ssldir below to use a directory besides the default ~/.vnc/certs
If your x11vnc binary was not compiled with OpenSSL library support, use of the -ssl option will induce an immediate failure and exit.  For such binaries, consider using the -stunnel option for SSL encrypted connections.
Misc Info: In temporary cert creation mode "TMP", set the env. var. X11VNC_SHOW_TMP_PEM=1 to have x11vnc print out the entire certificate, including the PRIVATE KEY part, to stderr.  There are better ways to get/save this info.  See "SAVE" above and "-sslGenCert" below.
-ssltimeout n
Set SSL read timeout to n seconds.  In some situations (i.e. an iconified viewer in Windows) the viewer stops talking and the connection is dropped after the default timeout (25s for about the first minute, 43200s later).  Set to zero to poll forever.  Set to a negative value to use the builtin setting.
Note that this value does NOT apply to the *initial* ssl init connection.  The default timeout for that is 20sec.  Use -env SSL_INIT_TIMEOUT=n to modify it.
-sslnofail
Exit at the first SSL connection failure. Useful when scripting SSL connections (e.g. x11vnc is started via ssh) and you do not want x11vnc waiting around for more connections, tying up ports, etc.
-ssldir dir
Use dir as an alternate ssl certificate and key management toplevel directory.  The default is ~/.vnc/certs
This directory is used to store server and other certificates and keys and also other materials.  E.g. in the simplest case, "-ssl SAVE" will store the x11vnc server cert in dir/server.pem
Use of alternate directories via -ssldir allows you to manage multiple VNC Certificate Authority (CA) keys.  Another use is if ~/.vnc/cert is on an NFS share you might want your certificates and keys to be on a local filesystem to prevent network snooping (for example -ssldir /var/lib/x11vnc-certs).
-ssldir affects nearly all of the other -ssl* options, e.g. -ssl SAVE, -sslGenCert, etc..
-sslverify path
For either of the -ssl or -stunnel modes, use path to provide certificates to authenticate incoming VNC *Client* connections (normally only the server is authenticated in SSL.)  This can be used as a method to replace standard password authentication of clients.
If path is a directory it contains the client (or CA) certificates in separate files.  If path is a file, it contains one or more certificates. See special tokens below.  These correspond to the "CApath = dir" and "CAfile = file" stunnel options.  See the stunnel(8) manpage for details.
Examples: x11vnc -ssl -sslverify ~/my.crt x11vnc -ssl -sslverify ~/my_pem_dir/
Note that if path is a directory, it must contain the certs in separate files named like <HASH>.0, where the value of <HASH> is found by running the command "openssl x509 -hash -noout -in file.crt". Evidently one uses <HASH>.1 if there is a collision...
The the key-management utility "-sslCertInfo HASHON" and "-sslCertInfo HASHOFF" will create/delete these hashes for you automatically (via symlink) in the HASH subdirs it manages.  Then you can point -sslverify to the HASH subdir.
Special tokens: in -ssl mode, if path is not a file or a directory, it is taken as a comma separated list of tokens that are interpreted as follows:
If a token is "CA" that means load the CA/cacert.pem file from the ssl directory.  If a token is "clients" then all the files clients/*.crt in the ssl directory are loaded.  Otherwise the file clients/token.crt is attempted to be loaded.  As a kludge, use a token like ../server-foo to load a server cert if you find that necessary.
Use -ssldir to use a directory different from the ~/.vnc/certs default.
Note that if the "CA" cert is loaded you do not need to load any of the certs that have been signed by it.  You will need to load any additional self-signed certs however.
Examples: x11vnc -ssl -sslverify CA x11vnc -ssl -sslverify self:fred,self:jim x11vnc -ssl -sslverify CA,clients
Usually "-sslverify CA" is the most effective.  See the -sslGenCA and -sslGenCert options below for how to set up and manage the CA framework.
NOTE: the following utilities, -sslGenCA, -sslGenCert, -sslEncKey, -sslCertInfo, and -sslCRL are provided for completeness, but for casual usage they are overkill.
They provide VNC Certificate Authority (CA) key creation and server / client key generation and signing.  So they provide a basic Public Key management framework for VNC-ing with x11vnc. (note that they require openssl(1) be installed on the system)
However, the simplest usage mode, "-ssl TMP" (where x11vnc automatically generates its own, self-signed, temporary key and the VNC viewers always accept it, e.g. accepting via a dialog box) is probably safe enough for most scenarios.  CA management is not needed.
To protect against Man-In-The-Middle attacks the "TMP" mode can be improved by using "-ssl SAVE" (same as "-ssl", i.e. the default) to have x11vnc create a longer term self-signed certificate, and then (safely) copy the corresponding public key cert to the desired client machines (care must be taken the private key part is not stolen; you will be prompted for a passphrase).
So keep in mind no CA key creation or management (-sslGenCA and -sslGenCert) is needed for either of the above two common usage modes.
One might want to use -sslGenCA and -sslGenCert if you had a large number of VNC client and server workstations.  That way the administrator could generate a single CA key with -sslGenCA and distribute its certificate part to all of the workstations.
Next, he could create signed VNC server keys (-sslGenCert server ...) for each workstation or user that then x11vnc would use to authenticate itself to any VNC client that has the CA cert.
Optionally, the admin could also make it so the VNC clients themselves are authenticated to x11vnc (-sslGenCert client ...) For this -sslverify would be pointed to the CA cert (and/or self- signed certs).
x11vnc will be able to use all of these cert and key files.  On the VNC client side, they will need to be "imported" somehow.  Web browsers have "Manage Certificates" actions as does the Java applet plugin Control Panel.  stunnel can also use these files (see the ss_vncviewer example script in the FAQ and SSVNC.)
-sslCRL path
Set the Certificate Revocation Lists (CRL) to path.  This setting applies for both -ssl and -stunnel modes.
If path is a file, the file contains one or more CRLs in PEM format.  If path is a directory, it contains hash named files of CRLs in the usual OpenSSL manner.  See the OpenSSL and stunnel(8) documentation for more info.
This option only applies if -sslverify has been supplied: it checks for revocation along the certificate chain used to verify the VNC client.  The -sslCRL setting will be ignored when -sslverify is not specified.
Note that if a CRL's expiration date has passed, all SSL connections will fail regardless of if they are related to the subject of the CRL or not.
Only rarely will one's x11vnc -ssl infrastructure be so large that this option would be useful (since normally maintaining the contents of the -sslverify file or directory should be enough.) However, when using x11vnc with a Certificate Authority (see -sslGenCA) to authenticate Clients via SSL/TLS, the -sslCRL option can be useful to revoke users' certs whose private SSL keys were lost or stolen (e.g. laptop.)  This way a new CA cert+key does not need to be created and new signed client keys generated and distributed to all users.
To create a CRL file with revoked certificates the commands 'openssl ca -revoke ...' and 'openssl ca -gencrl ...' are useful. (Run them in ~/.vnc/certs)
-sslGenCA [dir]
Generate your own Certificate Authority private key, certificate, and other files in directory [dir].  x11vnc then exits.
If [dir] is not supplied, a -ssldir setting is used, or otherwise ~/.vnc/certs is used.
This command also creates directories where server and client certs and keys will be stored.  The openssl(1) program must be installed on the system and available in PATH.
After the CA files and directories are created the x11vnc command exits; the VNC server is not run.
You will be prompted for information to put into the CA certificate.  The info does not have to be accurate just as long as clients accept the cert for VNC connections.  You will also need to supply a passphrase of at least 4 characters for the CA private key.
Once you have generated the CA you can distribute its certificate part, [dir]/CA/cacert.pem, to other workstations where VNC viewers will be run.  One will need to "import" this certificate in the applications, e.g. Web browser, Java applet plugin, stunnel, etc. Next, you can create and sign keys using the CA with the -sslGenCert option below.
Examples: x11vnc -sslGenCA x11vnc -sslGenCA  ~/myCAdir x11vnc -ssldir ~/myCAdir -sslGenCA
(the last two lines are equivalent)
-sslGenCert type name
Generate a VNC server or client certificate and private key pair signed by the CA created previously with -sslGenCA.  The openssl(1) program must be installed on the system and available in PATH.
After the Certificate is generated x11vnc exits; the VNC server is not run.
The type of key to be generated is the string type.  It is either "server" (i.e. for use by x11vnc) or "client" (for a VNC viewer). Note that typically only "server" is used: the VNC clients authenticate themselves by a non-public-key method (e.g. VNC or unix password).  type is required.
An arbitrary default name you want to associate with the key is supplied by the name string.  You can change it at the various prompts when creating the key.  name is optional.
If name is left blank for clients keys then "nobody" is used.  If left blank for server keys, then the primary server key: "server.pem" is created (this is the saved one referenced by "-ssl SAVE" when the server is started)
If name begins with the string "self:" then a self-signed certificate is created instead of one signed by your CA key.
If name begins with the string "req:" then only a key (.key) and a certificate signing *request* (.req) are generated.  You can then send the .req file to an external CA (even a professional one, e.g. Thawte) and then combine the .key and the received cert into the .pem file with the same basename.
The distinction between "server" and "client" is simply the choice of output filenames and sub-directory.  This makes it so the -ssl SAVE-name option can easily pick up the x11vnc PEM file this option generates.  And similarly makes it easy for the -sslverify option to pick up your client certs.
There is nothing special about the filename or directory location of either the "server" and "client" certs.  You can rename the files or move them to wherever you like.
Precede this option with -ssldir [dir] to use a directory other than the default ~/.vnc/certs You will need to run -sslGenCA on that directory first before doing any -sslGenCert key creation.
Note you cannot recreate a cert with exactly the same distiguished name (DN) as an existing one.  To do so, you will need to edit the [dir]/CA/index.txt file to delete the line.
Similar to -sslGenCA, you will be prompted to fill in some information that will be recorded in the certificate when it is created.
Tip: if you know the fully-qualified hostname other people will be connecting to, you can use that as the CommonName "CN" to avoid some applications (e.g. web browsers and java plugin) complaining that it does not match the hostname.
You will also need to supply the CA private key passphrase to unlock the private key created from -sslGenCA.  This private key is used to sign the server or client certificate.
The "server" certs can be used by x11vnc directly by pointing to them via the -ssl [pem] option.  The default file will be ~/.vnc/certs/server.pem.  This one would be used by simply typing -ssl SAVE.  The pem file contains both the certificate and the private key.  server.crt file contains the cert only.
The "client" cert + private key file will need to be copied and imported into the VNC viewer side applications (Web browser, Java plugin, stunnel, etc.)  Once that is done you can delete the "client" private key file on this machine since it is only needed on the VNC viewer side.  The, e.g. ~/.vnc/certs/clients/<name>.pem contains both the cert and private key.  The <name>.crt contains the certificate only.
NOTE: It is very important to know one should generate new keys with a passphrase.  Otherwise if an untrusted user steals the key file he could use it to masquerade as the x11vnc server (or VNC viewer client).  You will be prompted whether to encrypt the key with a passphrase or not.  It is recommended that you do.  One inconvenience to a passphrase is that it must be typed in EVERY time x11vnc or the client app is started up.
x11vnc -sslGenCert server x11vnc -ssl SAVE -display :0 ...
and then on viewer using ss_vncviewer stunnel wrapper (see the FAQ): ss_vncviewer -verify ./cacert.crt hostname:0
(this assumes the cacert.crt cert from -sslGenCA was safely copied to the VNC viewer machine where ss_vncviewer is run)
Example using a name:
x11vnc -sslGenCert server charlie x11vnc -ssl SAVE-charlie -display :0 ...
Example for a client certificate (rarely used):
x11vnc -sslGenCert client roger scp ~/.vnc/certs/clients/roger.pem somehost:.  rm  ~/.vnc/certs/clients/roger.pem
x11vnc is then started with the option -sslverify ~/.vnc/certs/clients/roger.crt (or simply -sslverify roger), and on the viewer user on somehost could do for example:
ss_vncviewer -mycert ./roger.pem hostname:0
If you set the env. var REQ_ARGS='...' it will be passed to openssl req(1).  A common use would be REQ_ARGS='-days 1095' to bump up the expiration date (3 years in this case).
-sslEncKey pem
Utility to encrypt an existing PEM file with a passphrase you supply when prompted.  For that key to be used (e.g. by x11vnc) the passphrase must be supplied each time.
The "SAVE" notation described under -ssl applies as well. (precede this option with -ssldir [dir] to refer a directory besides the default ~/.vnc/certs)
The openssl(1) program must be installed on the system and available in PATH.  After the Key file is encrypted the x11vnc command exits; the VNC server is not run.
Examples: x11vnc -sslEncKey /path/to/foo.pem x11vnc -sslEncKey SAVE x11vnc -sslEncKey SAVE-charlie
-sslCertInfo pem
Prints out information about an existing PEM file.  In addition the public certificate is also printed.  The openssl(1) program must be in PATH. Basically the command "openssl x509 -text" is run on the pem.
After the info is printed the x11vnc command exits; the VNC server is not run.
The "SAVE" notation described under -ssl applies as well.
Using  "LIST" will give a list of all certs being managed (in the ~/.vnc/certs dir, use -ssldir to refer to another dir).  "ALL" will print out the info for every managed key (this can be very long).  Giving a client or server cert shortname will also try a lookup (e.g. -sslCertInfo charlie).  Use "LISTL" or "LL" for a long (ls -l style) listing.
Using "HASHON" will create subdirs [dir]/HASH and [dir]/HASH with OpenSSL hash filenames (e.g. 0d5fbbf1.0) symlinks pointing up to the corresponding *.crt file.  ([dir] is ~/.vnc/certs or one given by -ssldir.)  This is a useful way for other OpenSSL applications (e.g. stunnel) to access all of the certs without having to concatenate them.  x11vnc will not use them unless you specifically reference them.  "HASHOFF" removes these HASH subdirs.
The LIST, LISTL, LL, ALL, HASHON, HASHOFF words can also be lowercase, e.g. "list".
-sslDelCert pem
Prompts you to delete all .crt .pem .key .req files associated with [pem].  x11vnc then exits. "SAVE" and lookups as in -sslCertInfo apply as well.
-sslScripts
Prints out both the 'genCA' and 'genCert' x11vnc openssl wrapper scripts for you to examine, modify, etc.  The scripts are printed to stdout and then the x11vnc program exits.
-stunnel [pem]
Use the stunnel(8) (stunnel.mirt.net) to provide an encrypted SSL tunnel between viewers and x11vnc.
This external tunnel method was implemented prior to the integrated -ssl encryption described above.  It still works well and avoids the requirement of linking with the OpenSSL libraries. This mode requires stunnel to be installed on the system and available via PATH (n.b. stunnel is often installed in sbin directories).  Version 4.x of stunnel is assumed (but see -stunnel3 below.)
[pem] is optional, use "-stunnel /path/to/stunnel.pem" to specify a PEM certificate file to pass to stunnel.  See the -ssl option for more info on certificate files.
Whether or not your stunnel has its own certificate depends on your stunnel configuration; stunnel often generates one at install time.  See your stunnel documentation for details.  In any event, if you want to use this certificate you must supply the full path to it as [pem].  Note: the file may only be readable by root.
[pem] may also be the special strings "TMP", "SAVE", and "SAVE..." as described in the -ssl option.  If [pem] is not supplied, "SAVE" is assumed.
Note that the VeNCrypt, ANONTLS, and "ANON" modes are not supported in -stunnel mode.
stunnel is started up as a child process of x11vnc and any SSL connections stunnel receives are decrypted and sent to x11vnc over a local socket.  The strings "The SSL VNC desktop is ..." and "SSLPORT=..."  are printed out at startup to indicate this.
The -localhost option is enforced by default to avoid people routing around the SSL channel.  Use -env STUNNEL_DISABLE_LOCALHOST=1 to disable this security requirement.
Set -env STUNNEL_DEBUG=1 for more debugging printout.
Set -env STUNNEL_PROG=xxx to the full path of stunnel program you want to be used (e.g. /usr/bin/stunnel4).