- x11vnc: 0.9.10 lastmod: 2010-04-28
- $ x11vnc --help
x11vnc: allow VNC connections to real X11 displays. 0.9.10 lastmod: 2010-04-28 (type "x11vnc -opts" to just list the options.) Typical usage is: Run this command in a shell on the remote machine "far-host" with X session you wish to view: x11vnc -display :0 Then run this in another window on the machine you are sitting at: vncviewer far-host:0 Once x11vnc establishes connections with the X11 server and starts listening as a VNC server it will print out a string: PORT=XXXX where XXXX is typically 5900 (the default VNC server port). One would next run something like this on the local machine: "vncviewer hostname:N" where "hostname" is the name of the machine running x11vnc and N is XXXX - 5900, i.e. usually "vncviewer hostname:0". By default x11vnc will not allow the screen to be shared and it will exit as soon as the client disconnects. See -shared and -forever below to override these protections. See the FAQ for details how to tunnel the VNC connection through an encrypted channel such as ssh(1). In brief: ssh -t -L 5900:localhost:5900 far-host 'x11vnc -localhost -display :0' vncviewer -encodings 'copyrect tight zrle hextile' localhost:0 Also, use of a VNC password (-rfbauth or -passwdfile) is strongly recommended. For additional info see: http://www.karlrunge.com/x11vnc/ and http://www.karlrunge.com/x11vnc/faq.html Config file support: if the file $HOME/.x11vncrc exists then each line in it is treated as a single command line option. Disable with -norc. For each option name, the leading character "-" is not required. E.g. a line that is either "forever" or "-forever" may be used and are equivalent. Likewise "wait 100" or "-wait 100" are acceptable and equivalent lines. The "#" character comments out to the end of the line in the usual way (backslash it for a literal). Leading and trailing whitespace is trimmed off. Lines may be continued with a "\" as the last character of a line (it becomes a space character). Options: -display disp X11 server display to connect to, usually :0. The X server process must be running on same machine and support MIT-SHM. Equivalent to setting the DISPLAY environment variable to "disp". See the description below of the "-display WAIT:..." extensions, where alias "-find" will find the user's display automatically, and "-create" will create a Xvfb session if no session is found. -auth file Set the X authority file to be "file", equivalent to setting the XAUTHORITY environment variable to "file" before startup. Same as -xauth file. See Xsecurity(7), xauth(1) man pages for more info. Use '-auth guess' to have x11vnc use its -findauth mechanism (described below) to try to guess the XAUTHORITY filename and use it. 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 -auth guess ... (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 -auth guess fails. (snip) -viewonly All VNC clients can only watch (default off). -shared VNC display is shared, i.e. more than one viewer can connect at the same time (default off). -once Exit after the first successfully connected viewer disconnects, opposite of -forever. This is the Default. -forever Keep listening for more connections rather than exiting as soon as the first client(s) disconnect. Same as -many -loop Create an outer loop restarting the x11vnc process whenever it terminates. -bg and -inetd are ignored in this mode (however see -loopbg below). Useful for continuing even if the X server terminates and restarts (at that moment the process will need permission to reconnect to the new X server of course). Use, e.g., -loop100 to sleep 100 millisecs between restarts, etc. Default is 2000ms (i.e. 2 secs) Use, e.g. -loop300,5 to sleep 300 ms and only loop 5 times. If -loopbg (plus any numbers) is specified instead, the "-bg" option is implied and the mode approximates inetd(8) usage to some degree. In this case when it goes into the background any listening sockets (i.e. ports 5900, 5800) are closed, so the next one in the loop can use them. This mode will only be of use if a VNC client (the only client for that process) is already connected before the process goes into the background, for example, usage of -display WAIT:.., -svc, and -connect can make use of this "poor man's" inetd mode. The default wait time is 500ms in this mode. This usage could use useful: -svc -bg -loopbg (snip) -inetd Launched by inetd(8): stdio instead of listening socket. Note: if you are not redirecting stderr to a log file (via shell 2> or -o option) you MUST also specify the -q option, otherwise the stderr goes to the viewer which will cause it to abort. Specifying both -inetd and -q and no -o will automatically close the stderr. (snip) -allow host1[,host2..] Only allow client connections from hosts matching the comma separated list of hostnames or IP addresses. Can also be a numerical IP prefix, e.g. "192.168.100." to match a simple subnet, for more control build LibVNCServer with libwrap support (See the FAQ). If the list contains a "/" it instead is a interpreted as a file containing addresses or prefixes that is re-read each time a new client connects. Lines can be commented out with the "#" character in the usual way. -allow applies in -ssl mode, but not in -stunnel mode. IPv6: as of x11vnc 0.9.10 a host can be specified in IPv6 numerical format, e.g. 2001:4860:b009::93. -localhost Basically the same as "-allow 127.0.0.1". Note: if you want to restrict which network interface x11vnc listens on, see the -listen option below. E.g. "-listen localhost" or "-listen 192.168.3.21". As a special case, the option "-localhost" implies "-listen localhost". A rare case, but for non-localhost -listen usage, if you use the remote control mechanism (-R) to change the -listen interface you may need to manually adjust the -allow list (and vice versa) to avoid situations where no connections (or too many) are allowed. If you do not want x11vnc to listen on ANY interface (evidently you are using -connect or -connect_or_exit, or plan to use remote control: -R connect:host), use -rfbport 0 IPv6: if IPv6 is supported, this option automatically implies the IPv6 loopback address '::1' as well. (snip) -passwdfile filename Specify the LibVNCServer password via the first line of the file "filename" (instead of via -passwd on the command line where others might see it via ps(1)). See the descriptions below for how to supply multiple passwords, view-only passwords, to specify external programs for the authentication, and other features. If the filename is prefixed with "rm:" it will be removed after being read. Perhaps this is useful in limiting the readability of the file. In general, the password file should not be readable by untrusted users (BTW: neither should the VNC -rfbauth file: it is NOT encrypted, only obscured with a fixed key). If the filename is prefixed with "read:" it will periodically be checked for changes and reread. It is guaranteed to be reread just when a new client connects so that the latest passwords will be used. If "filename" is prefixed with "cmd:" then the string after the ":" is run as an external command: the output of the command will be interpreted as if it were read from a password file (see below). If the command does not exit with 0, then x11vnc terminates immediately. To specify more than 1000 passwords this way set X11VNC_MAX_PASSWDS before starting x11vnc. The environment variables are set as in -accept. Note that due to the VNC protocol only the first 8 characters of a password are used (DES key). If "filename" is prefixed with "custom:" then a custom password checker is supplied as an external command following the ":". The command will be run when a client authenticates. If the command exits with 0 the client is accepted, otherwise it is rejected. The environment variables are set as in -accept. The standard input to the custom command will be a decimal digit "len" followed by a newline. "len" specifies the challenge size and is usually 16 (the VNC spec). Then follows len bytes which is the random challenge string that was sent to the client. This is then followed by len more bytes holding the client's response (i.e. the challenge string encrypted via DES with the user password in the standard situation). The "custom:" scheme can be useful to implement dynamic passwords or to implement methods where longer passwords and/or different encryption algorithms are used. The latter will require customizing the VNC client as well. One could create an MD5SUM based scheme for example. File format for -passwdfile: If multiple non-blank lines exist in the file they are all taken as valid passwords. Blank lines are ignored. Password lines may be "commented out" (ignored) if they begin with the character "#" or the line contains the string "__SKIP__". Lines may be annotated by use of the "__COMM__" string: from it to the end of the line is ignored. An empty password may be specified via the "__EMPTY__" string on a line by itself (note your viewer might not accept empty passwords). If the string "__BEGIN_VIEWONLY__" appears on a line by itself, the remaining passwords are used for viewonly access. For compatibility, as a special case if the file contains only two password lines the 2nd one is automatically taken as the viewonly password. Otherwise the "__BEGIN_VIEWONLY__" token must be used to have viewonly passwords. (tip: make the 3rd and last line be "__BEGIN_VIEWONLY__" to have 2 full-access passwords) (snip) -unixpw [list] Use Unix username and password authentication. x11vnc will use the su(1) program to verify the user's password. [list] is an optional comma separated list of allowed Unix usernames. If the [list] string begins with the character "!" then the entire list is taken as an exclude list. See below for per-user options that can be applied. A familiar "login:" and "Password:" dialog is presented to the user on a black screen inside the vncviewer. The connection is dropped if the user fails to supply the correct password in 3 tries or does not send one before a 45 second timeout. Existing clients are view-only during this period. If the first character received is "Escape" then the unix username will not be displayed after "login:" as it is typed. This could be of use for VNC viewers that automatically type the username and password. Since the detailed behavior of su(1) can vary from OS to OS and for local configurations, test the mode before deployment to make sure it is working properly. x11vnc will attempt to be conservative and reject a login if anything abnormal occurs. One case to note: FreeBSD and the other BSD's by default it is impossible for the user running x11vnc to validate his *own* password via su(1) (commenting out the pam_self.so entry in /etc/pam.d/su eliminates this behavior). So the x11vnc login will always *FAIL* for this case (even when the correct password is supplied). A possible workaround for this on *BSD would be to start x11vnc as root with the "-users +nobody" option to immediately switch to user nobody where the su'ing will proceed normally. Another source of potential problems are PAM modules that prompt for extra info, e.g. password aging modules. These logins will fail as well even when the correct password is supplied. **IMPORTANT**: to prevent the Unix password being sent in *clear text* over the network, one of two schemes will be enforced: 1) the -ssl builtin SSL mode, or 2) require both -localhost and -stunnel be enabled. Method 1) ensures the traffic is encrypted between viewer and server. A PEM file will be required, see the discussion under -ssl below (under some circumstances a temporary one can be automatically generated). Method 2) requires the viewer connection to appear to come from the same machine x11vnc is running on (e.g. from a ssh -L port redirection). And that the -stunnel SSL mode be used for encryption over the network. (see the description of -stunnel below). Note: as a convenience, if you ssh(1) in and start x11vnc it will check if the environment variable SSH_CONNECTION is set and appears reasonable. If it does, then the -ssl or -stunnel requirement will be dropped since it is assumed you are using ssh for the encrypted tunnelling. -localhost is still enforced. Use -ssl or -stunnel to force SSL usage even if SSH_CONNECTION is set. To override the above restrictions you can set environment variables before starting x11vnc: Set UNIXPW_DISABLE_SSL=1 to disable requiring either -ssl or -stunnel (as under SSH_CONNECTION.) Evidently you will be using a different method to encrypt the data between the vncviewer and x11vnc: perhaps ssh(1) or an IPSEC VPN. -localhost is still enforced (however, see the next paragraph.) Set UNIXPW_DISABLE_LOCALHOST=1 to disable the -localhost requirement in -unixpw modes. One should never do this (i.e. allow the Unix passwords to be sniffed on the network.) This also disables the localhost requirement for reverse connections (see below.) Note that use of -localhost with ssh(1) (and no -unixpw) is roughly the same as requiring a Unix user login (since a Unix password or the user's public key authentication is used by sshd on the machine where x11vnc runs and only local connections from that machine are accepted). Regarding reverse connections (e.g. -R connect:host and -connect host), when the -localhost constraint is in effect then reverse connections can only be used to connect to the same machine x11vnc is running on (default port 5500). Please use a ssh or stunnel port redirection to the viewer machine to tunnel the reverse connection over an encrypted channel. In -inetd mode the Method 1) will be enforced (not Method 2). With -ssl in effect reverse connections are disabled. If you override this via env. var, be sure to also use encryption from the viewer to inetd. Tip: you can also have your own stunnel spawn x11vnc in -inetd mode (thereby bypassing inetd). See the FAQ for details. The user names in the comma separated [list] may have per-user options after a ":", e.g. "fred:opts" where "opts" is a "+" separated list of "viewonly", "fullaccess", "input=XXXX", or "deny", e.g. "karl,wally:viewonly,boss:input=M". For "input=" it is the K,M,B,C described under -input. If an item in the list is "*" that means those options apply to all users. It ALSO implies all users are allowed to log in after supplying a valid password. Use "deny" to explicitly deny some users if you use "*" to set a global option. If [list] begins with the "!" character then "*" is ignored for checking if the user is allowed, but the option values associated with it do apply as normal. There are also some utilities for checking passwords if [list] starts with the "%" character. See the quick_pw() function for more details. Description: "%-" or "%stdin" means read one line from stdin. "%env" means it is in $UNIXPW env var. A leading "%/" or "%." means read the first line from the filename that follows after the % character. % by itself means prompt for the username and password. Otherwise: %user:pass E.g. -unixpw %fred:swordfish For the other cases user:pass is read from the indicated source. If the password is correct 'Y user' is printed and the program exit code is 0. If the password is incorrect it prints 'N user' and the exit code is 1. If there is some other error the exit code is 2. This feature enables x11vnc to be a general unix user password checking tool; it could be used from scripts or other programs. These % password checks also apply to the -unixpw_nis and -unixpw_cmd options. For the % password check, if the env. var. UNIXPW_CMD is set to a command then it is run as the user (assuming the password is correct.) The output of the command is not printed, the program or script must manage that by some other means. The exit code of x11vnc will depend on the exit code of the command that is run. Use -nounixpw to disable unixpw mode if it was enabled earlier in the cmd line (e.g. -svc mode) (snip) -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). -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. 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. (snip) -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" 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). 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. To troubleshoot the FINDCREATEDISPLAY mechanism, set the following env. var. to an ouput log file, e.g -env CREATE_DISPLAY_OUTPUT=/tmp/mydebug.txt 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. 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. 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)). 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.) 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. 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 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). 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. (snip) -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. (snip) -usepw If no other password method was supplied on the command line, first look for ~/.vnc/passwd and if found use it with -rfbauth; next, look for ~/.vnc/passwdfile and use it with -passwdfile; otherwise, prompt the user for a password to create ~/.vnc/passwd and use it with the -rfbauth option. If none of these succeed x11vnc exits immediately. -storepasswd pass file Store password "pass" as the VNC password in the file "file". Once the password is stored the program exits. Use the password via "-rfbauth file" If called with no arguments, "x11vnc -storepasswd", the user is prompted for a password and it is stored in the file ~/.vnc/passwd. Called with one argument, that will be the file to store the prompted password in. -nopw Disable the big warning message when you use x11vnc without some sort of password. (snip) -users list If x11vnc is started as root (say from inetd(8) or from display managers xdm(1), gdm(1), etc), then as soon as possible after connections to the X display are established try to switch to one of the users in the comma separated "list". If x11vnc is not running as root this option is ignored. Why use this option? In general it is not needed since x11vnc is already connected to the X display and can perform its primary functions. The option was added to make some of the *external* utility commands x11vnc occasionally runs work properly. In particular under GNOME and KDE to implement the "-solid color" feature external commands (gconftool-2 and dcop) unfortunately must be run as the user owning the desktop session. Since this option switches userid it also affects the userid used to run the processes for the -accept and -gone options. It also affects the ability to read files for options such as -connect, -allow, and -remap and also the ultra and tight filetransfer feature if enabled. Note that the -connect file is also sometimes written to. So be careful with this option since in some situations its use can decrease security. In general the switch to a user will only take place if the display can still be successfully opened as that user (this is primarily to try to guess the actual owner of the session). Example: "-users fred,wilma,betty". Note that a malicious local user "barney" by quickly using "xhost +" when logging in may possibly get the x11vnc process to switch to user "fred". What happens next? Under display managers it may be a long time before the switch succeeds (i.e. a user logs in). To instead make it switch immediately regardless if the display can be reopened prefix the username with the "+" character. E.g. "-users +bob" or "-users +nobody". The latter (i.e. switching immediately to user "nobody") is the only obvious use of the -users option that increases security. Use the following notation to associate a group with a user: user1.group1,user2.group2,... Note that initgroups(2) will still be called first to try to switch to ALL of a user's groups (primary and additional groups). Only if that fails or it is not available then the single group specified as above (or the user's primary group if not specified) is switched to with setgid(2). Use -env X11VNC_SINGLE_GROUP=1 to prevent trying initgroups(2) and only switch to the single group. This sort of setting is only really needed to make the ultra or tight filetransfer permissions work properly. This format applies to any comma separated list of users, even the special "=" modes described below. In -unixpw mode, if "-users unixpw=" is supplied then after a user authenticates himself via the -unixpw mechanism, x11vnc will try to switch to that user as though "-users +username" had been supplied. If you want to limit which users this will be done for, provide them as a comma separated list after "unixpw=" Groups can also be specified as described above. Similarly, in -ssl mode, if "-users sslpeer=" is supplied then after an SSL client authenticates with his cert (the -sslverify option is required for this) x11vnc will extract a UNIX username from the "emailAddress" field (username@hostname.com) of the "Subject" of the x509 SSL cert and then try to switch to that user as though "-users +username" had been supplied. If you want to limit which users this will be done for, provide them as a comma separated list after "sslpeer=". Set the env. var X11VNC_SSLPEER_CN to use the Common Name (normally a hostname) instead of the Email field. NOTE: for sslpeer= mode the x11vnc administrator must take care that any client certs he adds to -sslverify have the intended UNIX username in the "emailAddress" field of the cert. Otherwise a user may be able to log in as another. This command can be of use in checking: "openssl x509 -text -in file.crt", see the "Subject:" line. Also, along with the normal RFB_* env. vars. (see -accept) passed to external cmd= commands, RFB_SSL_CLIENT_CERT will be set to the client's x509 certificate string. The sslpeer= mode can aid finding X sessions via the FINDDISPLAY and FINDCREATEDISPLAY mechanisms. To immediately switch to a user *before* connections to the X display are made or any files opened use the "=" character: "-users =bob". That user needs to be able to open the X display and any files of course. The special user "guess=" means to examine the utmpx database (see who(1)) looking for a user attached to the display number (from DISPLAY or -display option) and try him/her. To limit the list of guesses, use: "-users guess=bob,betty". Even more sinister is the special user "lurk=" that means to try to guess the DISPLAY from the utmpx login database as well. So it "lurks" waiting for anyone to log into an X session and then connects to it. Specify a list of users after the = to limit which users will be tried. To enable a different searching mode, if the first user in the list is something like ":0" or ":0-2" that indicates a range of DISPLAY numbers that will be tried (regardless of whether they are in the utmpx database) for all users that are logged in. Also see the "-display WAIT:..." functionality. Examples: "-users lurk=" and also "-users lurk=:0-1,bob,mary" Be especially careful using the "guess=" and "lurk=" modes. They are not recommended for use on machines with untrustworthy local users. (snip) -o logfile Write stderr messages to file "logfile" instead of to the terminal. Same as "-logfile file". To append to the file use "-oa file" or "-logappend file". If "logfile" contains the string "%VNCDISPLAY" it is expanded to the vnc display (the name may need to be guessed at.) "%HOME" works too. -flag file Write the "PORT=NNNN" (e.g. PORT=5900) string to "file" in addition to stdout. This option could be useful by wrapper script to detect when x11vnc is ready. -rmflag file Remove "file" at exit to signal when x11vnc is done. The file is created at startup if it does not already exist or if "file" is prefixed with "create:". If the file is created, the x11vnc PID is placed in the file. Otherwise the files contents is not changed. Use prefix "nocreate:" to prevent creation. -rc filename Use "filename" instead of $HOME/.x11vncrc for rc file. -norc Do not process any .x11vncrc file for options. -env VAR=VALUE Set the environment variable 'VAR' to value 'VALUE' at x11vnc startup. This is a convenience utility to avoid shell script wrappers, etc. to set the env. var. You may specify as many of these as needed on the command line. -prog /path/to/x11vnc Set the full path to the x11vnc program for cases when it cannot be determined from argv[0] (e.g. tcpd/inetd) -h, -help Print this help text. -?, -opts Only list the x11vnc options. -V, -version Print program version and last modification date. -license Print out license information. Same as -copying and -warranty. -dbg Instead of exiting after cleaning up, run a simple "debug crash shell" when fatal errors are trapped. -q, -quiet Be quiet by printing less informational output to stderr. (use -noquiet to undo an earlier -quiet.) The -quiet option does not eliminate all informational output, it only reduces it. It is ignored in most auxiliary usage modes, e.g. -storepasswd. To eliminate all output use: 2>/dev/null 1>&2, etc. -v, -verbose Print out more information to stderr. -bg Go into the background after screen setup. Messages to stderr are lost unless -o logfile is used. Something like this could be useful in a script: port=`ssh -t $host "x11vnc -display :0 -bg" | grep PORT` port=`echo "$port" | sed -e 's/PORT=//'` port=`expr $port - 5900` vncviewer $host:$port (snip) -ping n Send a 1x1 framebuffer update to all clients every n seconds (e.g. to try to keep a network connection alive) (snip) These options are passed to LibVNCServer: -rfbport port TCP port for RFB protocol -rfbwait time max time in ms to wait for RFB client -rfbauth passwd-file use authentication on RFB protocol (use 'storepasswd' to create a password file) -rfbversion 3.x Set the version of the RFB we choose to advertise -permitfiletransfer permit file transfer support -passwd plain-password use authentication (use plain-password as password, USE AT YOUR RISK) -deferupdate time time in ms to defer updates (default 40) -deferptrupdate time time in ms to defer pointer updates (default none) -desktop name VNC desktop name (default "LibVNCServer") -alwaysshared always treat new clients as shared -nevershared never treat new clients as shared -dontdisconnect don't disconnect existing clients when a new non-shared connection comes in (refuse new connection instead) -httpdir dir-path enable http server using dir-path home -httpport portnum use portnum for http connection -enablehttpproxy enable http proxy support -progressive height enable progressive updating for slow links -listen ipaddr listen for connections only on network interface with addr ipaddr. '-listen localhost' and hostname work too. libvncserver-tight-extension options: -disablefiletransfer disable file transfer -ftproot string set ftp root
- $ sudo x11vnc
############################################################### #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@# #@ @# #@ ** WARNING ** WARNING ** WARNING ** WARNING ** @# #@ @# #@ YOU ARE RUNNING X11VNC WITHOUT A PASSWORD!! @# #@ @# #@ This means anyone with network access to this computer @# #@ may be able to view and control your desktop. @# #@ @# #@ >>> If you did not mean to do this Press CTRL-C now!! <<< @# #@ @# #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@# #@ @# #@ You can create an x11vnc password file by running: @# #@ @# #@ x11vnc -storepasswd password /path/to/passfile @# #@ or x11vnc -storepasswd /path/to/passfile @# #@ or x11vnc -storepasswd @# #@ @# #@ (the last one will use ~/.vnc/passwd) @# #@ @# #@ and then starting x11vnc via: @# #@ @# #@ x11vnc -rfbauth /path/to/passfile @# #@ @# #@ an existing ~/.vnc/passwd file from another VNC @# #@ application will work fine too. @# #@ @# #@ You can also use the -passwdfile or -passwd options. @# #@ (note -passwd is unsafe if local users are not trusted) @# #@ @# #@ Make sure any -rfbauth and -passwdfile password files @# #@ cannot be read by untrusted users. @# #@ @# #@ Use x11vnc -usepw to automatically use your @# #@ ~/.vnc/passwd or ~/.vnc/passwdfile password files. @# #@ (and prompt you to create ~/.vnc/passwd if neither @# #@ file exists.) Under -usepw, x11vnc will exit if it @# #@ cannot find a password to use. @# #@ @# #@ @# #@ Even with a password, the subsequent VNC traffic is @# #@ sent in the clear. Consider tunnelling via ssh(1): @# #@ @# #@ http://www.karlrunge.com/x11vnc/#tunnelling @# #@ @# #@ Or using the x11vnc SSL options: -ssl and -stunnel @# #@ @# #@ Please Read the documention for more info about @# #@ passwords, security, and encryption. @# #@ @# #@ http://www.karlrunge.com/x11vnc/faq.html#faq-passwd @# #@ @# #@ To disable this warning use the -nopw option, or put @# #@ the setting in your ~/.x11vncrc file. @# #@ @# #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@# ############################################################### (snip) Some tips and guidelines: ** An X server (the one you wish to view) must be running before x11vnc is started: x11vnc does not start the X server. (however, see the -create option if that is what you really want). ** You must use -display <disp>, -OR- set and export your $DISPLAY environment variable to refer to the display of the desired X server. - Usually the display is simply ":0" (in fact x11vnc uses this if you forget to specify it), but in some multi-user situations it could be ":1", ":2", or even ":137". Ask your administrator or a guru if you are having difficulty determining what your X DISPLAY is. ** Next, you need to have sufficient permissions (Xauthority) to connect to the X DISPLAY. Here are some Tips: - Often, you just need to run x11vnc as the user logged into the X session. So make sure to be that user when you type x11vnc. - Being root is usually not enough because the incorrect MIT-MAGIC-COOKIE file may be accessed. The cookie file contains the secret key that allows x11vnc to connect to the desired X DISPLAY. - You can explicitly indicate which MIT-MAGIC-COOKIE file should be used by the -auth option, e.g.: x11vnc -auth /home/someuser/.Xauthority -display :0 x11vnc -auth /tmp/.gdmzndVlR -display :0 you must have read permission for the auth file. See also '-auth guess' and '-findauth' discussed below. ** If NO ONE is logged into an X session yet, but there is a greeter login program like "gdm", "kdm", "xdm", or "dtlogin" running, you will need to find and use the raw display manager MIT-MAGIC-COOKIE file. Some examples for various display managers: gdm: -auth /var/gdm/:0.Xauth -auth /var/lib/gdm/:0.Xauth kdm: -auth /var/lib/kdm/A:0-crWk72 -auth /var/run/xauth/A:0-crWk72 xdm: -auth /var/lib/xdm/authdir/authfiles/A:0-XQvaJk dtlogin: -auth /var/dt/A:0-UgaaXa Sometimes the command "ps wwwwaux | grep auth" can reveal the file location. Starting with x11vnc 0.9.9 you can have it try to guess by using: -auth guess (see also the x11vnc -findauth option.) Only root will have read permission for the file, and so x11vnc must be run as root (or copy it). The random characters in the filenames will of course change and the directory the cookie file resides in is system dependent. See also: http://www.karlrunge.com/x11vnc/faq.html
Last modified 14 years ago
Last modified on Mar 7, 2011 1:04:04 AM
