Xvnc(1)

NAME
Xvnc - an X server providing VNC connectivity

SYNOPSIS

Xvnc
    [:display] [-geometry widthxheight] [-depth depth] [-pixelformat rgbNNN|bgrNNN] [-udpinputport port] [-rfbport port] [-rfbwait time] [-nocursor] [-rfbauth passwd-file] [-securitytypes type-list] [-x509cert cert] [-x509key key] [-pamsession] [-noreverse] [-noclipboardsend] [-noclipboardrecv] [-maxclipboard bytes] [-idletimeout time] [-httpd dir] [-httpport port] [-deferupdate time] [-noflowcontrol] [-alr time] [-alrqual level] [-alrsamp 1X|2X|4X|gray] [-interframe] [-nointerframe] [-virtualtablet] [-economictranslate] [-desktop name] [-alwaysshared] [-nevershared] [-disconnect] [-viewonly] [-localhost] [-interface ipaddr] [-ipv6] [-inetd] [-compatiblekbd] [-mt] [-nthreads thread-count] [X-options...]

DESCRIPTION
Xvnc is a VNC (Virtual Network Computing) server for Unix and Linux systems. It acts like a normal X server, except that it sends its output to a virtual rather than a physical display. Remote machines can connect to the VNC server and see/control the output of this virtual display [see vncviewer(1).] Xvnc is built using the XFree86 source code and shares many options with it. Normally, you don't need to start Xvnc manually-- use the vncserver(1) wrapper script instead. This script sets reasonable defaults for the Xvnc session, checks many error conditions, etc. Please read the SECURITY CONCERNS section if you plan to use VNC on an untrusted network.

OPTIONS
Xvnc supports many standard X server options and a number of VNC-specific options. To see which standard X server options are supported, please look at the output of Xvnc -help and read the Xserver(1) manual page. The VNC-specific options are as follows:

-geometry widthxheight
    Set width and height of the virtual X display.

-pixelformat rgbNNN|bgrNNN
    Specify the pixel format of the virtual X display. Xvnc can use any pixel format you choose, but if this pixel format does not match the pixel format of the display on which vncviewer is running, then Xvnc will perform pixel format conversion prior to sending images to vncviewer. This can slow performance. The default pixel format, rgb888, is equivalent to BGRA on little endian systems or ARGB on big endian systems. A pixel format of bgr888 is equivalent to RGBA on little endian systems or ABGR on big endian systems.

-udpinputport port
    UDP port for keyboard/pointer data.

-rfbport port
    TCP port that the server should use when listening for connections from normal VNC viewers.

-rfbwait time
    Maximum time, in milliseconds, to wait for an RFB client (VNC viewer.)

-nocursor
    Don't display a mouse pointer on the remote desktop.

-rfbauth passwd-file
    Specify the password file to use with VNC Password authentication. passwd-file can be created using the vncpasswd(1) utility. This argument has no effect if permitted-security-types is specified in the security configuration file and none of the VNC security types are listed as permitted security types.

-securitytypes type-list
    type-list is a comma-separated list of security types that should be enabled for this Xvnc session. Refer to the SECURITY OVERVIEW section below for a description of available security types. Only security types that are permitted in the security configuration file will actually be enabled. If type-list contains no permitted security types, then Xvnc will exit with an error. If this argument is not specified, then Xvnc uses a default value of "TLSVnc, TLSOtp, TLSPlain, X509Vnc, X509Otp, X509Plain, VNC, OTP, UnixLogin, Plain". Security types are case-insensitive.

-x509cert cert
    Specify the X.509 signed certificate file (in PEM format) to use with X.509 encryption. This argument has no effect if permitted-security-types is specified in the security configuration file and none of the X.509 security types are listed as permitted security types.

-x509key key
    Specify the X.509 private key file (in PEM format) to use with X.509 encryption. This argument has no effect if permitted-security-types is specified in the security configuration file and none of the X.509 security types are listed as permitted security types.

-pamsession
    Create a new PAM session for each viewer that authenticates using the username/password of the user who owns the TurboVNC session, and leave the PAM session open until the viewer disconnects. When using Kerberos, this causes pam_krb5 to create a Kerberos ticket for the TurboVNC session, which can be reused within the session to provide access to other services. This option can be disabled for all TurboVNC sessions on this system by using the no-pam-sessions directive in the security configuration file. See the SECURITY CONFIGURATION FILE section for more details.

-noreverse
    Do not allow reverse VNC connections to be made from this Xvnc session. This option can be set for all TurboVNC sessions on this system by using the no-reverse-connections directive in the security configuration file. See the SECURITY CONFIGURATION FILE section for more details.

-noclipboardsend
    Disable outbound clipboard synchronization. This prevents the clipboard of any connected viewers from being synchronized with the clipboard of the TurboVNC session whenever the latter changes. This option can be set for all TurboVNC sessions on this system by using the no-clipboard-send directive in the security configuration file. See the SECURITY CONFIGURATION FILE section for more details.

-noclipboardrecv
    Disable inbound clipboard synchronization. This prevents the clipboard of the TurboVNC session from being synchronized with the clipboard of a connected viewer whenever the latter changes. This option can be set for all TurboVNC sessions on this system by using the no-clipboard-recv directive in the security configuration file. See the SECURITY CONFIGURATION FILE section for more details.

-maxclipboard bytes
    Set the maximum clipboard transfer size to bytes.

-idletimeout time
    Time, in seconds, which the TurboVNC Server can sit idle (with no VNC viewer connections) before it automatically exits (default: no timeout.) This argument has no effect if the max-idle-timeout directive is specified in the security configuration file and if that value is lower than time.

-httpd dir
    Specify directory where the Java viewer classes are located.

-httpport port
    TCP port that the server should use when listening for connections from Java-enabled web browsers.

-deferupdate time
    Time, in milliseconds, for which to defer screen updates (default: 40). Deferring updates helps to coalesce many small desktop changes into a few larger updates, thus saving network bandwidth.

-noflowcontrol
    Normally, the TurboVNC Server will use the RFB flow control extensions (Continuous Updates and Fence) with any connected viewers that support them. These extensions allow the server to send framebuffer updates at the maximum rate that the network connection and the viewer can handle, instead of waiting for viewers to explicitly request updates. Disabling flow control causes the TurboVNC Server to send framebuffer updates at the maximum rate that the network connection can handle, irrespective of the viewer. For full-screen video and 3D applications, this may produce smoother animation on high-latency networks, although it will almost certainly also produce a noticeable lag between mouse movement and application response, since the TCP buffers will be 100% full.

-alr time
    Enable the automatic lossless refresh (ALR) feature for this Xvnc session and set the timeout to time seconds. If ALR is enabled and no framebuffer updates have been sent to a given viewer in the past time seconds, and if "eligible" areas of the screen have been transmitted to that viewer using JPEG since the last lossless refresh, then those areas of the screen are re-transmitted using mathematically lossless image compression (specifically, the Lossless Tight + Zlib encoding method.) The default behavior is to only allow regions drawn using X[Shm]PutImage() or CopyRect to be eligible for ALR. The intent of this behavior is to restrict ALR mainly to the pixels drawn by VirtualGL, but it also prevents blinking cursors (which are usually drawn using XCopyArea()) from confusing the ALR algorithm. You can, however, set the TVNC_ALRALL environment variable to 1 to make all screen regions eligible for ALR. You can also set TVNC_ALRCOPYRECT to 0 to make screen regions drawn with CopyRect ineligible for ALR (approximating the behavior of TurboVNC 1.2.1 and prior.)

-alrqual level
    Instead of sending a mathematically lossless image for an automatic lossless refresh, send a JPEG image with the specified JPEG quality (95 is a good choice, as this is the equivalent of the "Tight + Perceptually Lossless JPEG" preset.)

-alrsamp 1X|2X|4X|gray
    Specify the level of chrominance subsampling to be used when sending an automatic lossless refresh (default: 1X.) This has no effect unless -alrqual is also specified.

-interframe
    Normally, the TurboVNC Server will enable interframe comparison whenever Compression Level 5 or above is requested (if using Tight encoding, compression levels 5-7 are equivalent to compression levels 0-2 with interframe comparison enabled.) Specifying -interframe will enable interframe comparison all the time, regardless of the compression level that was requested by the viewer. Interframe comparison maintains a copy of the remote framebuffer for each connected viewer and compares each framebuffer update with the copy to ensure that redundant updates are not sent to the viewer. This prevents unnecessary network traffic if an ill-behaved application draws the same thing over and over again, but interframe comparison also causes the TurboVNC Server to use more CPU time and much more memory, and thus it is recommended that this feature be used only when needed.

-nointerframe
    Specifying this option will disable interframe comparison, regardless of the compression level that was requested by the viewer.

-virtualtablet
    TurboVNC can handle extended input devices in one of two ways: Remote X Input Mode (default) X Input devices are created in the TurboVNC X server only when a viewer requests their creation. For instance, the TurboVNC Un*x/Linux Viewer sends information about client-side X Input extended pointer devices to the server, and the server makes copies of those devices. The viewer then sends extended input events from the client-side devices to the server, where they are mapped to the respective copies of the client-side devices. If another viewer attempts to create a remote X Input device with the same name, then the existing server-side device is shared with the new viewer. The server-side devices are deleted automatically when all viewers that use them have disconnected. This is the most flexible way of handling extended input devices, because it allows any generic X Input pointer device (spaceballs, tablets, etc.) on the client machine to be used by the server. Virtual Tablet Mode (enabled with this command-line option) In Virtual Tablet Mode, the TurboVNC Server creates virtual stylus, eraser, touch, and pad devices designed to emulate a Wacom tablet, and it maps all extended input events from all viewers to these devices (events from client-side stylus, eraser, touch, and pad devices are mapped to the corresponding virtual device on the server, and other events are ignored.) This mode is less generic than Remote X Input Mode, and it probably will not work with devices other than tablets (perhaps not even with non-Wacom tablets.) Virtual Tablet mode is useful when running specific applications from xstartup.turbovnc, rather than a window manager. Because applications usually check for the presence of X Input devices at startup, by the time the first viewer connects and requests that the client-side devices be cloned, it is too late.

-economictranslate
    Use less memory-hungry pixel format translation.

-desktop name
    Set VNC desktop name ("x11" by default).

-alwaysshared
    Always treat new connections as shared. Never disconnect existing users or deny new connections when a new user tries to connect to a VNC session that is already occupied.

-nevershared
    Never treat new connections as shared. Do not allow simultaneous user connections to the same VNC session.

-disconnect
    Disconnect existing users when a new non-shared connection is established, rather than refusing the new connection.

-viewonly
    Don't accept keyboard and pointer events from viewers. All viewers will be able to see the desktop but won't be able to control it.

-localhost
    Only allow loopback connections from localhost. This option is useful in conjunction with SSH tunneling. This option can be set for all TurboVNC sessions on this system by using the no-remote-connections directive in the security configuration file. See the SECURITY CONFIGURATION FILE section for more details. Unless -ipv6 is also specified, only connections from IPv4 clients are accepted.

-interface ipaddr
    Listen only on the network interface with the given ipaddr.

-ipv6
    Enable IPv6 support. If your system supports IPv4-mapped IPv6 addresses, then this option causes Xvnc to accept both local and remote connections from both IPv4 and IPv6 clients. Otherwise, only connections from IPv6 clients will be accepted. If -localhost is also specified, or if the no-remote-connections directive is specified in the security configuration file, then this option causes Xvnc to accept only local connections from IPv6 clients (the equivalent of specifying -interface ::1).

-inetd
    If Xvnc is launched by inetd, this option causes Xvnc to redirect network input/output to stdin/stdout.

-compatiblekbd
    Set META and ALT keys to the same X modifier flag, as in the original version of Xvnc by AT&T labs (this option is specific to TightVNC/TurboVNC.)

-mt Enable multithreaded Tight encoding

-nthreads thread-count
    Specify the number of threads to use with multithreaded Tight encoding. The default is to use one thread per CPU core, up to a maximum of 4 (because using more than 4 encoding threads breaks compatibility with viewers other than the TurboVNC Viewer.) The server will not allow the thread count to exceed 8, nor to exceed the number of CPU cores.

SECURITY EXTENSIONS
The TurboVNC Server supports 13 security types, each of which specifies an authentication scheme (a technique used to transmit authentication credentials from a VNC viewer to the VNC server), an authentication method (a technique used by the VNC server to validate the authentication credentials), and an encryption method. The authentication methods that the TurboVNC Server supports are as follows:

None
    No authentication. Xvnc will not enable any security types that use this authentication method unless no other security types are enabled. This authentication method should generally only be used in conjunction with SSH or another security mechanism that provides authentication outside of the context of Xvnc.

VNC Password
    Authenticate using a VNC password file created by the vncpasswd(1) utility and specified with the -rfbauth command-line argument to Xvnc. This authentication method uses the Standard VNC authentication scheme to receive authentication credentials from a VNC viewer. The Standard VNC authentication scheme encrypts the VNC password using 56-bit DES, which is a weak form of encryption.

One-Time Password (OTP)
    Authenticate using a one-time password. OTPs for full control or view-only access can be created using the vncpasswd(1) utility. OTPs are discarded by Xvnc immediately after they are used, so an additional OTP must be generated before another user is allowed to connect using this method. OTP authentication is handy for sharing a VNC session with another person with whom you do not wish to share your VNC password. This authentication method uses the Standard VNC authentication scheme to receive authentication credentials from a VNC viewer.

PAM User/Password
    Authenticate using Pluggable Authentication Modules (PAM). This authentication method is typically used to authenticate against Unix login credentials, but it can also be used to authenticate against any other user/password authentication credentials that can be accessed through PAM. A valid PAM service configuration must be created by the system administrator (see the SECURITY CONFIGURATION FILE section for details.) On some systems, it may be necessary to make the Xvnc binary setuid root in order to authenticate against credentials other than those of the user running Xvnc. PAM User/Password authentication uses the TightVNC Unix Login or the VeNCrypt Plain authentication scheme to receive authentication credentials from a VNC viewer. Since both of those authentication schemes transmit the password using plain text, it is strongly recommended that TLS or SSH encryption be enforced in the security configuration file if any security types using PAM User/Password authentication are permitted.

The security types that the TurboVNC Server supports are as follows:

None
    No encryption and no authentication. This security type can be used with VNC viewers that understand the "None" RFB security type or the "Tight" RFB security type with the "None" authentication capability.

TLSNone
    Anonymous TLS (Transport Layer Security) encryption with no authentication. This security type can be used with VNC viewers that understand the "VeNCrypt" RFB security type with the "TLSNone" VeNCrypt sub-type.

X509None
    TLS encryption with a specified X.509 certificate and no authentication. This security type can be used with VNC viewers that understand the "VeNCrypt" RFB security type with the "X509None" VeNCrypt sub-type.

VNC VNC Password/Standard VNC authentication with no encryption. This security type can be used with VNC viewers that understand the "VNC" RFB security type or the "Tight" RFB security type with the "VNC" authentication capability.

TLSVnc
    Anonymous TLS encryption with VNC Password/Standard VNC authentication. This security type can be used with VNC viewers that understand the "VeNCrypt" RFB security type with the "TLSVnc" VeNCrypt sub-type.

X509Vnc
    TLS encryption with a specified X.509 certificate and VNC password/Standard VNC authentication. This security type can be used with VNC viewers that understand the "VeNCrypt" RFB security type with the "X509Vnc" VeNCrypt sub-type.

OTP One-Time Password authentication with no encryption. This security type can be used with VNC viewers that understand the "VNC" RFB security type or the "Tight" RFB security type with the "VNC" authentication capability.

TLSOtp
    Anonymous TLS encryption with One-Time Password/Standard VNC authentication. This security type can be used with VNC viewers that understand the "VeNCrypt" RFB security type with the "TLSVnc" VeNCrypt sub-type.

X509Otp
    TLS encryption with a specified X.509 certificate and One-Time Password/Standard VNC authentication. This security type can be used with VNC viewers that understand the "VeNCrypt" RFB security type with the "X509Vnc" VeNCrypt sub-type.

Plain
    PAM User/Password / Plain authentication with no encryption. This security type can be used with VNC viewers that understand the "VeNCrypt" RFB security type and the "Plain" VeNCrypt sub-type.

TLSPlain
    Anonymous TLS encryption with PAM User/Password / Plain authentication. This security type can be used with VNC viewers that understand the "VeNCrypt" RFB security type with the "TLSPlain" VeNCrypt sub-type.

X509Plain
    TLS encryption with a specified X.509 certificate and PAM User/Password / Plain authentication. This security type can be used with VNC viewers that understand the "VeNCrypt" RFB security type with the "X509Plain" VeNCrypt sub-type.

UnixLogin
    PAM User/Password / Unix Login authentication with no encryption. This security type can be used with VNC viewers that understand the "Tight" RFB security type with the "Unix Login" authentication capability.

The security type that will be selected when a VNC viewer connects depends on the following:

Xvnc command-line options
    The -securitytypes argument allows you to request that specific security types be enabled in Xvnc.

The permitted-security-types directive
    If the security configuration file exists, then the system administrator can use the permitted-security-types directive in that file to specify the security types that are allowed on the system. A security type must both be requested, by way of the -securitytypes argument (or in the default security types that Xvnc uses if that argument is not specified), and permitted in order for the security type to be enabled. If none of the security types meet this criteria, then Xvnc exits with an error. For instance, if "TLSVnc" is the only permitted security type, then it is an error to start Xvnc with -securitytypes X509Vnc. The permitted-security-types directive also allows you to specify the order in which authentication schemes are advertised to VNC viewers. For instance, if "UnixLogin" is listed first, then the TurboVNC Viewer will default to using Unix Login authentication when connecting to any TurboVNC sessions on this server. Similarly, if "VNC" or "OTP" is listed first, then the TurboVNC Viewer will default to using Standard VNC authentication. If the security configuration file does not exist or permitted-security-types is not specified, then Xvnc behaves as if permitted-security-types was set to "TLSVnc, TLSOtp, TLSPlain, TLSNone, X509Vnc, X509Otp, X509Plain, X509None, VNC, OTP, UnixLogin, Plain, None".

The negotiated RFB protocol version
    This is determined by the VNC viewer's capabilities. Older VNC viewers that support RFB version 3.3 can only use the "None", "VNC", or "OTP" security types. Newer viewers that support RFB 3.7 or later with the Tight RFB security extension can use the "UnixLogin" security type, if the viewer has implemented it. Viewers that support RFB 3.7 or later with the VeNCrypt RFB security extension can use the "TLS*", "X509*", and "Plain" security types, if the viewer has implemented them. Authentication will fail if a viewer that does not support or enable any of the TurboVNC Server's permitted security types attempts to connect.

The VNC viewer user interface
    The VNC viewer's user interface may place additional restrictions on which security types can be used. For example, the TurboVNC Viewer has command-line options that allow you to force the use of the VNC or Unix Login authentication schemes, regardless of which scheme the server advertises as the default.

You can examine the Xvnc log file to see details of authentication processing, including the authentication methods, RFB protocol versions, and security types that have been enabled.

SECURITY CONFIGURATION FILE
At startup, Xvnc reads security configuration information from /etc/turbovncserver-security.conf. For security reasons, this pathname is hard-coded into the Xvnc executable and cannot be changed without rebuilding Xvnc. If present, the security configuration file must be owned by either root or by the user who started the Xvnc server, and the file may not be writable by others. Comment lines start with a hash (#) character. Spaces and tabs are ignored on lines containing configuration directives. The configuration directives are:

enable-user-acl
    If the "PAM User/Password" authentication method is used, then this directive enables the Xvnc server's internal user access control list (ACL) to further limit which users will be permitted to attempt PAM authentication. Users can be added to or removed from this list using the vncpasswd(1) utility. The user who started the Xvnc server will automatically be added to the access control list.

max-idle-timeout=time
    This specifies the maximum idle timeout (in seconds) for all TurboVNC sessions started on this machine. The idle timeout is the amount of time that a TurboVNC session can remain idle (with no VNC viewer connections) before Xvnc automatically exits. If this value is set to a number greater than 0, then all TurboVNC sessions on this machine will use this idle timeout value by default, and the user will only be allowed to override it with a lower value.

max-desktop-size=widthxheight
    This specifies the maximum desktop size for all TurboVNC sessions started on this machine. If a user attempts to start a session with a larger geometry than this or to use remote desktop resizing to increase the desktop size to a size larger than this, the desktop size will be clamped to widthxheight.

no-clipboard-send
    This prevents any TurboVNC server sessions started on this machine from sending clipboard changes to their connected viewers.

no-clipboard-recv
    This prevents any TurboVNC server sessions started on this machine from receiving clipboard changes from their connected viewers.

no-reverse-connections
    Do not allow reverse connections to be made from any TurboVNC server started on this machine. This causes Xvnc to ignore requests from the vncconnect(1) utility.

no-remote-connections
    Do not allow inbound remote connections to be made to any TurboVNC server started on this machine. Only connections from localhost can be made, which effectively forces the use of SSH tunneling to make inbound remote connections.

no-httpd
    Disable the built-in HTTP server in all TurboVNC servers started on this machine.

no-x11-tcp-connections
    Do not allow X11 TCP connections to any TurboVNC server started on this machine.

no-pam-sessions
    Do not allow PAM sessions to be created for any TurboVNC servers started on this machine.

pam-service-name=svcname
    Sets the service name to be used when Xvnc performs PAM authentication. The default service name is turbovnc. This typically corresponds to a file in /etc/pam.d or to a token in /etc/pam.conf. For instance, if your system has a file named /etc/pam.d/passwd, then copying this file to /etc/pam.d/{svcname} would cause the username and password sent by the VNC viewer to be validated against /etc/passwd.

permitted-security-types=type[,type[...]]
    Defines the initial set of permitted security types. Multiple comma-separated types may be specified. Accepted values for type are: TLSVnc, TLSOtp, TLSPlain, TLSNone, X509Vnc, X509Otp, X509Plain, X509None, VNC, OTP, UnixLogin, Plain, and None. Security types are case-insensitive. The order in which these types are specified defines the order in which Xvnc will advertise the corresponding RFB security types and authentication schemes to the VNC viewer. This ordering may affect which security type the VNC viewer chooses as its default.

SECURITY CONCERNS

Even when used with encryption, there are other security problems inherent in the design of VNC. Thus, it is recommended that you restrict network access to Xvnc servers from untrusted network addresses. Probably the best way to secure an Xvnc server is to allow only loopback connections from the server machine (using the -localhost option or the no-remote-connections security configuration file directive) and to use SSH tunneling for remote access to the Xvnc server. For details on using TurboVNC with SSH tunneling, see the TurboVNC User's Guide.

It is incumbent upon the system administrator to ensure that a security type meets the security requirements for a particular site before it is permitted to be used. In particular, caution should be exercised when using security types that support the Unix Login and Plain authentication schemes. Unless SSH tunneling or another suitable encryption mechanism is enforced, then the use of these authentication schemes will result in Unix passwords being sent unencrypted over the network.

SEE ALSO
vncserver(1), vncviewer(1), vncpasswd(1), vncconnect(1), sshd(1)

AUTHORS
VNC was originally developed at AT&T Laboratories Cambridge. TightVNC additions were implemented by Constantin Kaplinsky. TurboVNC, based on TightVNC, is provided by The VirtualGL Project. Many other people participated in development, testing and support. Man page authors:
Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
Tim Waugh <twaugh@redhat.com>
Constantin Kaplinsky <const@tightvnc.com>
D. R. Commander <information@turbovnc.org>
Craig Ruff <cruff@ucar.edu>