Difference between revisions of "TigerVNC"

From ArchWiki
Jump to navigation Jump to search
(update interlanguage links)
Tag: wiki-scripts
 
(186 intermediate revisions by 34 users not shown)
Line 1: Line 1:
[[Category:Security]]
 
 
[[Category:Remote desktop]]
 
[[Category:Remote desktop]]
 +
[[Category:Servers]]
 
[[de:VNC]]
 
[[de:VNC]]
 
[[es:TigerVNC]]
 
[[es:TigerVNC]]
[[ja:Vncserver]]
+
[[ja:TigerVNC]]
[[ru:Vncserver]]
+
[[zh-hans:Virtual Network Computing]]
[[zh-cn:Virtual Network Computing]]
 
 
{{Related articles start}}
 
{{Related articles start}}
 
{{Related|x11vnc}}
 
{{Related|x11vnc}}
 
{{Related articles end}}
 
{{Related articles end}}
[http://tigervnc.org/ TigerVNC] is an implementation of the [[Wikipedia:VNC|VNC]] protocol. This article focuses on the server functionality.
+
[http://tigervnc.org/ TigerVNC] is an implementation of the [[Wikipedia:Virtual Network Computing|Virtual Network Computing]] (VNC) protocol. This article focuses on the server functionality.
  
 
== Installation ==
 
== Installation ==
  
 
[[Install]] the {{Pkg|tigervnc}} package.  
 
[[Install]] the {{Pkg|tigervnc}} package.  
{{Note|This packages provides the requisite vncserver, x0vncserver and also vncviewer.}}
 
  
Vncserver provides two major remote control abilities:
+
Two VNC servers are available with TigerVNC:
# Virtual (headless) server which is similar to the standard X server, but has a virtual screen rather than a physical one.  The virtual server runs completely ''parallel'' to the physical X server should one be running.
+
# ''Xvnc'' is the default and recommended server for TigerVNC. It is both a VNC server and an X server with a virtual framebuffer. This means it is similar to the standard X server but has a virtual screen rather than a physical one.  The virtual server runs in parallel with the physical X server should one be running. ''vncserver'' is a wrapper script which eases the starting of ''Xvnc''. See [[#Running vncserver for virtual (headless) sessions]] for more information.
# Direct control of the local X session(s) which do run on the physical monitor.
+
# ''x0vncserver'' provides direct control of the local X session(s) which are running on the physical monitor. It continuously polls the X display which is a simple but inefficient implementation. See [[#Running x0vncserver to directly control the local display]] for more information.
 +
 
 +
TigerVNC also provides ''vncviewer'' which is a client viewer for VNC.
  
 
== Running vncserver for virtual (headless) sessions ==
 
== Running vncserver for virtual (headless) sessions ==
  
=== Create environment, config, and password files ===
+
=== Create password, startup and config files ===
Vncserver will create its initial environment, config, and user password file the first time it is run.  These will be stored in {{ic|~/.vnc}} which will be created if not present.
+
The first time ''vncserver'' is run, it creates its initial environment, config, and user password file.  These will be stored in {{ic|~/.vnc}} which will be created if not present. See {{man|1|vncserver}} for the complete manual.
  
 
{{hc|$ vncserver|
 
{{hc|$ vncserver|
Line 31: Line 31:
 
Verify:
 
Verify:
  
New 'mars:1 (facade)' desktop is mars:1
+
New 'mycomputer:1 (theusername)' desktop is mycomputer:1
  
Creating default startup script /home/facade/.vnc/xstartup
+
Creating default startup script /home/theusername/.vnc/xstartup
Starting applications specified in /home/facade/.vnc/xstartup
+
Starting applications specified in /home/theusername/.vnc/xstartup
Log file is /home/facade/.vnc/mars:1.log
+
Log file is /home/theusername/.vnc/mycomputer:1.log
 
}}
 
}}
  
Notice the :1 trailing the hostname.  This is indicating the TCP port number on which the virtual vncserver is running.  In this case, :1 is actually TCP port 5901 (5900+1).  Running {{ic|vncserver}} a second time will create a second instance running on the next highest, free port, i.e 5902 (5900+2) which shall end in :2 as above.
+
Note the {{ic|:1}} trailing the hostname in the output messages of the script.  This indicates the TCP port number on which the virtual VNC server is running.  In this case, {{ic|:1}} is actually TCP port 5901 (5900+1).  Running {{ic|vncserver}} a second time will create a second instance running on the next highest, free port, i.e 5902 (5900+2) which shall end in {{ic|:2}} as above.
  
{{Note|Linux systems can have as many VNC servers as physical memory allows, all of which running in parallel to each other.}}
+
{{Note|Linux systems can have as many VNC servers as memory allows, all of which will be running in parallel to each other.}}
  
Shutdown the vncserver by using the -kill switch:
+
To shutdown the just created VNC server, use the {{ic|-kill}} switch:
 
  $ vncserver -kill :1
 
  $ vncserver -kill :1
  
==== Edit the environment file ====
+
If at any stage one needs to change the previously defined password, the ''vncpasswd'' tool can be called:
 +
$ vncpasswd
 +
See {{man|1|vncpasswd}} for more information.
 +
 
 +
==== Edit the startup script ====
  
Vncserver sources {{ic|~/.vnc/xstartup}} which functions like an [[.xinitrc]] file. At a minimum, users should start a DE from this file.  For more, see: [[General recommendations#Desktop environments]].
+
The {{ic|~/.vnc/xstartup}} script is sourced by ''vncserver'' for creating the virtual X session and it must be adapted to one's needs.
 +
It functions like an [[.xinitrc]] file. In this script, users are expected to start a [[Desktop environment]], see: [[General recommendations#Desktop environments]].
  
For example, starting lxqt:
+
For example, to start [[Xfce]], the following script can be used:
  
 
{{hc|~/.vnc/xstartup|
 
{{hc|~/.vnc/xstartup|
<nowiki>#!/bin/sh
+
#!/bin/sh
exec startlxqt
+
unset SESSION_MANAGER
</nowiki>}}
+
unset DBUS_SESSION_BUS_ADDRESS
 +
exec startxfce4}}
 +
 
 +
{{Note|The instruction {{ic|unset DBUS_SESSION_BUS_ADDRESS}} clears the variable and forces {{ic|startxfce4}} to initiate a new bus for the VNC session. If [[D-Bus]] fails to start, try using {{ic|exec dbus-launch startxfce4}} instead to launch the bus manually, note that this latter way of starting ''D-Bus'' is deprecated.}}
 +
 
 +
To start [[GNOME]], replace {{ic|exec startxfce4}} by {{ic|exec dbus-launch gnome-session}} in the example above.
 +
 
 +
To start [[Cinnamon]], replace {{ic|exec startxfce4}} by {{ic|exec dbus-launch cinnamon-session}} in the example above.
 +
 
 +
Make sure {{ic|~/.vnc/xstartup}} has a execute permission.
  
 
==== Edit the optional config file ====
 
==== Edit the optional config file ====
  
With the release of tigervnc 1.60-1, support for parsing options in {{ic|~/.vnc/config}} has been implemented which obviates the need to call {{ic|vncserver}} with command line switches. The format is one option per line. An example is provided:
+
''vncserver'' supports parsing parameters through the command line, or in the file {{ic|~/.vnc/config}}. The format of the config file is one option per line, option names are case-insensitive and commenting with {{ic|#}} is supported.
{{hc|~/.vnc/config|
+
The parameters can be either ''vncserver'' specific or can be parameters that are passed to ''Xvnc'', see {{man|1|vncserver}} or {{man|1|Xvnc}} for the full list of available options.
<nowiki>
+
 
## Supported server options to pass to vncserver upon invocation can be listed
+
An example is provided below:
## in this file. See the following manpages for more: vncserver(1) Xvnc(1).
+
{{hc|~/.vnc/config|2=
## Several common ones are shown below. Uncomment and modify to your liking.
 
##
 
 
securitytypes=tlsvnc
 
securitytypes=tlsvnc
 
desktop=sandbox
 
desktop=sandbox
Line 70: Line 82:
 
dpi=96
 
dpi=96
 
localhost
 
localhost
alwaysshared
+
alwaysshared}}
</nowiki>}}
 
  
 
=== Starting and stopping vncserver via systemd ===
 
=== Starting and stopping vncserver via systemd ===
Systemd can manage the vncserver via a service in one of two modes using either a user or system service.  Both are presented below.
+
''Systemd'' can manage the vncserver by either running it in system or in user mode.  Both ways are presented below.
  
 
==== User mode ====
 
==== User mode ====
{{Note|In order to keep the vncserver alive when the user logs out (physically or via ssh), one must enable the linger option for loginctl like this: {{ic|# loginctl enable-linger username}} Failure to do so will result in the vncserver getting killed when the user logs off the machine.}}
 
  
Start the service in usermode:
+
The user mode is the most straightforward way to run the VNC server as a service. [[Start]] and [[enable]] {{ic|vncserver@:1.service}} in [[Systemd/User]] mode, i.e. with the {{ic|--user}} parameter. The {{ic|:1}} option can be replaced by another display number, it is the increment over 5900 the VNC server listens to. In the previous example, one connects to the server through port 5901.
$ systemctl --user start vncserver@:1
 
  
Enable the service in usermode:
+
{{Note|The vncserver will get killed when the user logs off the machine, see [[Systemd/User#Automatic start-up of systemd user instances]] for related configuration.}}
$ systemctl --user enable vncserver@:1
 
  
 
==== System mode ====
 
==== System mode ====
  
{{Warning|Do not run this service if your local area network is untrusted.}}
+
Create {{ic|/etc/systemd/system/vncserver@'':1''.service}}. As in user mode above, {{ic|:1}} is the port increment over 5900 to which the VNC server will be listening for connections (e.g  {{ic|vncserver@:5.service}} means the server will be listening to port 5905). Edit the service unit by defining the user ({{ic|1=User=}}) to run the server, and the desired ''vncserver'' options.
 
 
Create {{ic|/etc/systemd/system/vncserver@'':1''.service}}, where {{ic|:1}} is the {{ic|$DISPLAY}} [[environment variable]].  
 
 
 
Modify the service by defining the user ({{ic|1=User=}}) to run the server, and the desired [[Vncserver]] options ({{ic|1=usr/bin/vncserver %i -arg1 -arg2 -argn}}).
 
  
{{hc|/etc/systemd/system/vncserver@'':1''.service|<nowiki>
+
{{hc|/etc/systemd/system/vncserver@'':1''.service|2=
 
[Unit]
 
[Unit]
 
Description=Remote desktop service (VNC)
 
Description=Remote desktop service (VNC)
Line 102: Line 106:
 
User=foo
 
User=foo
 
PAMName=login
 
PAMName=login
 
+
PIDFile=/home/%u/.vnc/%H%i.pid
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
+
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 {{!}}{{!}} :'
ExecStart=/usr/bin/vncserver -geometry 1440x900 -alwaysshared -fg %i
+
ExecStart=/usr/bin/vncserver %i -geometry 1440x900 -alwaysshared -fg
 
ExecStop=/usr/bin/vncserver -kill %i
 
ExecStop=/usr/bin/vncserver -kill %i
  
 
[Install]
 
[Install]
WantedBy=multi-user.target
+
WantedBy=multi-user.target}}
</nowiki>}}
 
  
 
[[Start]] {{ic|vncserver@'':1''.service}} and optionally [[enable]] it to run at boot time/shutdown.
 
[[Start]] {{ic|vncserver@'':1''.service}} and optionally [[enable]] it to run at boot time/shutdown.
  
==== Multi-user mode ====
+
==== On demand multi-user mode ====
One can use systemd socket activation in combination with [[Xdmcp|XDMCP]] to automatically spawn VNC servers for each user who attempts to login, so there is no need to set up one server/port per user. This setup uses the display manager to authenticate users and login, so there is no need for VNC passwords. The downside is that users cannot leave a session running on the server and reconnect to it later.
+
One can use ''systemd'' socket activation in combination with [[XDMCP]] to automatically spawn VNC servers for each user who attempts to login, so there is no need to set up one server/port per user. This setup uses the display manager to authenticate users and login, so there is no need for VNC passwords. The downside is that users cannot leave a session running on the server and reconnect to it later.
To get this running, first set up [[Xdmcp|XDMCP]] and make sure the display manager is running.
+
 
 +
To get this running, first set up [[XDMCP]] and make sure the display manager is running.
 
Then create:
 
Then create:
{{hc|/etc/systemd/system/xvnc.socket|
+
{{hc|/etc/systemd/system/xvnc.socket|2=
<nowiki>
 
 
[Unit]
 
[Unit]
 
Description=XVNC Server
 
Description=XVNC Server
Line 127: Line 130:
  
 
[Install]
 
[Install]
WantedBy=sockets.target
+
WantedBy=sockets.target}}
</nowiki>}}
+
{{hc|/etc/systemd/system/xvnc@.service|2=
{{hc|/etc/systemd/system/xvnc@.service|
 
<nowiki>
 
 
[Unit]
 
[Unit]
 
Description=XVNC Per-Connection Daemon
 
Description=XVNC Per-Connection Daemon
Line 138: Line 139:
 
User=nobody
 
User=nobody
 
StandardInput=socket
 
StandardInput=socket
StandardError=syslog
+
StandardError=syslog}}
</nowiki>}}
 
 
Use systemctl to [[start]] and [[enable]] {{ic|xvnc.socket}}. Now any number of users can get unique desktops by connecting to port 5900.
 
Use systemctl to [[start]] and [[enable]] {{ic|xvnc.socket}}. Now any number of users can get unique desktops by connecting to port 5900.
  
If the VNC server is exposed to the internet, add the {{ic|-localhost}} option to {{ic|Xvnc}} in {{ic|xvnc@.service}} and follow the instructions below about connecting over SSH (Note that the 'localhost' in {{ic|-query localhost}} is not {{ic|-localhost}}). Since we only select a user after connecting, the VNC server runs as user 'nobody' and uses xvnc directly instead of the 'vncserver' script, so any options in ~/.vnc are ignored. Optionally [[autostart]] {{ic|vncconfig}} so that the clipboard works ({{ic|vncconfig}} exits immediately in non-VNC sessions). One way is to create:
+
If the VNC server is exposed to the internet, add the {{ic|-localhost}} option to {{ic|Xvnc}} in {{ic|xvnc@.service}} (note that {{ic|-query localhost}} and {{ic|-localhost}} are different switches) and follow [[#Accessing vncserver via SSH tunnels]]. Since we only select a user after connecting, the VNC server runs as user ''nobody'' and uses {{ic|Xvnc}} directly instead of the {{ic|vncserver}} script, so any options in {{ic|~/.vnc}} are ignored. Optionally, [[autostart]] ''vncconfig'' so that the clipboard works (''vncconfig'' exits immediately in non-VNC sessions). One way is to create:
 
{{hc|/etc/X11/xinit/xinitrc.d/99-vncconfig.sh|
 
{{hc|/etc/X11/xinit/xinitrc.d/99-vncconfig.sh|
<nowiki>
 
 
#!/bin/sh
 
#!/bin/sh
vncconfig -nowin &
+
vncconfig -nowin &}}
</nowiki>}}
 
 
 
== Running vncserver to directly control the local display ==
 
  
=== Using tigervnc's x0vncserver ===
+
== Running x0vncserver to directly control the local display ==
{{Pkg|tigervnc}} provides the x0vncserver binary which allows direct control over a physical X session.  Invoke it like so:
 
$ x0vncserver -display :0 -passwordfile ~/.vnc/passwd
 
  
For more see
+
As mentioned in [[#Installation]], the ''tigervnc'' package also provides the x0vncserver binary which allows direct control over a physical X session.
  man x0vncserver
+
After defining a session password using the ''vncpasswd'' tool, invoke the server like so:
 +
  $ x0vncserver -rfbauth ~/.vnc/passwd
  
==== Starting and stopping x0vncserver via systemd ====
+
For more information, see {{man|1|x0vncserver}}.
  
{{Warning|Do not run this service if your local area network is untrusted!}}
+
{{Note|''x0vncserver'' is an inefficient VNC server which continuously polls any X display, allowing it to be controlled via VNC. It is intended mainly as a demonstration of a simple VNC server. [[x11vnc]] is an alternative more advanced VNC server which also provides direct control of the current X session.}}
  
In order to have a VNC Server runnning x0vncserver, which is the easiest way for most users to quickly have remote access to the current desktop, you can create a systemd unit.
+
=== Starting x0vncserver via xprofile ===
 +
A simple way to start ''x0vncserver'' is adding a line in one of the [[xprofile]] files such as:
  
{{Note|This unit will only be useful if the user in the unit is currently running a X session.}}
+
{{hc|~/.xprofile|
 +
...
 +
x0vncserver -rfbauth ~/.vnc/passwd &}}
  
Create {{ic|/etc/systemd/system/x0vncserver.service}} and modify it defining the user to run the server, and the desired options.
+
=== Starting and stopping x0vncserver via systemd ===
 +
In order to have a VNC Server running ''x0vncserver'', which is the easiest way for most users to quickly have remote access to the current desktop, create a systemd unit as follows replacing the user and the options with the desired ones:
  
{{hc|/etc/systemd/system/x0vncserver.service|
+
{{hc|~/.config/systemd/user/x0vncserver.service|2=
<nowiki>
 
 
[Unit]
 
[Unit]
 
Description=Remote desktop service (VNC)
 
Description=Remote desktop service (VNC)
After=syslog.target network.target
 
  
 
[Service]
 
[Service]
Type=forking
+
Type=simple
User=foo
+
# wait for Xorg started by ${USER}
ExecStart=/usr/bin/sh -c '/usr/bin/x0vncserver -display :0 -rfbport 5900 -passwordfile /home/foo/.vnc/passwd &'
+
ExecStartPre=/bin/sh -c 'while ! pgrep -U "$USER" Xorg; do sleep 2; done'
 +
ExecStart=/usr/bin/x0vncserver -rfbauth %h/.vnc/passwd
 +
# or login with your username & password
 +
#ExecStart=/usr/bin/x0vncserver -PAMService=login -PlainUsers=${USER} -SecurityTypes=TLSPlain
  
 
[Install]
 
[Install]
WantedBy=multi-user.target
+
WantedBy=default.target}}
</nowiki>}}
 
  
=== Using x11vnc ===
+
[[Start]] and [[enable]] the service {{ic|x0vncserver.service}} in [[Systemd/User]] mode, i.e. with the {{ic|--user}} parameter.
Another option is to use {{pkg|x11vnc}} which has the advantage or disadvantage, depending on one's perspective, of requiring root to initiate the access.  For more, see: [[X11vnc]].
 
  
 
== Connecting to vncserver ==
 
== Connecting to vncserver ==
{{Warning|It is ill-advised to connect insecurely to a vncserver outside of the LAN; readers are encouraged read the rest of this article in its entirety if use cases require connections outside of one's LAN. That being said, TigerVNC ''is encrypted by default'' unless it is specifically instructed otherwise by setting SecurityTypes to a non-secure option, although this lacks identity verification and will not prevent MITM attack during the connection setup. X509Vnc is the recommended option for a secure connection.}}
+
{{Warning|The default's TigerVNC security method is not secure, it lacks identity verification and will not prevent man-in-the-middle attack during the connection setup. Make sure you understand the security settings of your server and do not connect insecurely to a vncserver outside of a trusted LAN.}}
  
Any number of clients can connect to a vncserver.  A simple example is given below where vncserver is running on 10.1.10.2 on port 5901 (:1) in shorthand notation:
+
{{Note|By default, TigerVNC uses the ''TLSVnc'' authentication/encryption method unless specifically instructed via the {{ic|SecurityTypes}} parameter. With ''TLSVnc'', there is standard VNC authentication and traffic is encrypted with GNUTLS but the identity of the server is not verified. TigerVNC supports alternative security schemes such as ''X509Vnc'' that combines standard VNC authentication with GNUTLS encryption and server identification, this is the recommended mode for a secure connection.
 +
 
 +
When {{ic|SecurityTypes}} on the server is set to a non-encrypted option as high-priority (such as ''None'', ''VncAuth'', ''Plain'', ''TLSNone'', ''TLSPlain'', ''X509None'', ''X509Plain''); which is ill-advised, then it is not possible to use encryption. When running ''vncviewer'', it is safer to explicitly set {{ic|SecurityTypes}} and not accept any unencrypted traffic. Any other mode is to be used only when [[#Accessing vncserver via SSH tunnels]]. }}
 +
 
 +
Any number of clients can connect to a vncserver.  A simple example is given below where vncserver is running on 10.1.10.2 port 5901, or :1 in shorthand notation:
 
  $ vncviewer 10.1.10.2:1
 
  $ vncviewer 10.1.10.2:1
  
Line 196: Line 198:
 
The {{ic|-passwd}} switch allows one to define the location of the server's {{ic|~/.vnc/passwd}} file. It is expected that the user has access to this file on the server through [[SSH]] or through physical access. In either case, place that file on the client's file system in a safe location, i.e. one that has read access ONLY to the expected user.
 
The {{ic|-passwd}} switch allows one to define the location of the server's {{ic|~/.vnc/passwd}} file. It is expected that the user has access to this file on the server through [[SSH]] or through physical access. In either case, place that file on the client's file system in a safe location, i.e. one that has read access ONLY to the expected user.
  
  $ vncviewer -passwd /path/to/server-passwd-file
+
  $ vncviewer -passwd ''/path/to/server-passwd-file''
 +
 
 +
The password can also be provided directly.
 +
 
 +
{{Note|The password below is not secured; anyone who can run {{ic|ps}} on the machine will see it.}}
 +
 
 +
$ vncviewer -passwd <(echo MYPASSWORD | vncpasswd -f)
  
 
=== Example GUI-based clients ===
 
=== Example GUI-based clients ===
Line 205: Line 213:
 
* {{Pkg|vinagre}}
 
* {{Pkg|vinagre}}
 
* {{Pkg|remmina}}
 
* {{Pkg|remmina}}
* {{Pkg|vncviewer-jar}}
+
* {{Pkg|virt-viewer}}
 +
* {{AUR|vncviewer-jar}}
  
 
TigerVNC's vncviewer also has a simple GUI when run without any parameters:
 
TigerVNC's vncviewer also has a simple GUI when run without any parameters:
Line 211: Line 220:
  
 
== Accessing vncserver via SSH tunnels ==
 
== Accessing vncserver via SSH tunnels ==
An advantage of SSH tunneling is one does not need to open up another port to the outside, since the traffic is literally tunneled through the SSH port which the user already has open to the WAN.  It is highly recommended to use the {{ic|-localhost}} switch when running vncserver with this method since this switch only allows connections ''from the localhost'' and by analogy, only by users physically ssh'ed and authenticated on the box.
+
For servers offering SSH connection, an advantage of this method is that it is not necessary to open any other port than the already opened SSH port to the outside, since the VNC traffic is tunneled through the SSH port.
  
{{Note|TigerVNC uses TLSVnc encryption by default, unless specifically instructed via the SecurityTypes parameter. Authentication and traffic is encrypted, but there is no identity verification. TigerVNC supports alternative encryption schemes such as X509Vnc that allows the client to verify the identity of the server.
+
=== On the server ===
 +
On the server side, ''vncserver'' or ''x0vncserver'' must be run.
  
When the SecurityTypes on the server side is set to a non-secure option as high-priority (such as None, VncAuth, Plain, TLSNone, TLSPlain, X509None, X509Plain; which is ill-advised), it is not possible to use encryption.  In that case, one can tunnel the VNC over SSHWhen running vncviewer, it is a good idea to explicitly set SecurityTypes and not accept any unencrypted traffic.}}
+
When running ''vncserver'', it is recommended to use the {{ic|-localhost}} switch way since it allows connections from the localhost only and by analogy, only from users ssh'ed and authenticated on the box. For example run a command such as:
 +
  $ vncserver -geometry 1440x900 -alwaysshared -dpi 96 '''-localhost''' :1
  
=== On the server ===
+
For ''x0vncserver'', this {{ic|-localhost}} switch is not available but a workaround is to use the {{ic|-HostsFile}} option and create the below file that will be provided as a parameter:
Below is an example invoking vncserver with the -localhost flag:
+
{{hc|~/.vnc/hostsfile|
$ vncserver -geometry 1440x900 -alwaysshared -dpi 96 -localhost :1
+
+127.0.0.1
 +
+::1
 +
-}}
 +
It will only accept connection from localhost in IPv4 or IPv6 address standard.
  
Alternatively, simply add the "localhost" option as a single line in {{ic|~/.vnc/config}}.  Below is the example above in this format:
+
The corresponding command is:
{{hc|~/.vnc.config|
+
$ x0vncserver -HostsFile ~/.vnc/hostsfile -SecurityTypes none
<nowiki>
 
## Supported server options to pass to vncserver upon invocation can be listed
 
## in this file. See the following manpages for more: vncserver(1) Xvnc(1).
 
## Several common ones are shown below. Uncomment and modify to your liking.
 
##
 
geometry=1200x700
 
alwaysshared
 
dpi=96
 
localhost
 
</nowiki>}}
 
  
 
=== On the client ===
 
=== On the client ===
 +
The VNC server has been setup on the remote machine to only accept local connections.
 +
Now, the client must open a secure shell with the remote machine (10.1.10.2 in this example) and create a tunnel from the client port, for instance 9901, to the remote server 5901 port. For more details on this feature, see [[OpenSSH#Forwarding other ports]] and {{man|1|ssh}}.
  
With the server now only accepting connection from the localhost, connect to the box via ssh using the -L switch to enable tunnels.  For more on this feature, see the manpage for ssh itself.
+
  $ ssh 10.1.10.2 -L 9901:localhost:5901
For example:
 
 
 
$ ssh 10.1.10.2 -L 5901:localhost:5901
 
 
 
This forwards the server port 5901 to the client box also on port 5901.  Note that one does not have to match the port numbers on the server and client.  For example:
 
 
 
  $ ssh 10.1.10.2 -L 8900:localhost:5901
 
  
This forwards the server port 5901 to the client box on port 8900.
+
Once connected via SSH, leave this shell window open since it is acting as the secured tunnel with the server. Alternatively, directly run SSH in the background using the {{ic|-f}} option. On the client side, to connect via this encrypted tunnel, point the ''vncviewer'' to the forwarded client port on the localhost.
  
Once connected via SSH, leave that xterm or shell window open since it is acting as the secured tunnel to/from server. To connect via this encrypted tunnel, simply point the vncviewer to the client port on the localhost.
+
  $ vncviewer localhost:9901
  
Using the matched ports on the server/client:
+
What happens in practice is that the vncviewer connects locally to port 9901 which is tunneled to the server's localhost port 5901. The connection is established to the right port within the secure shell.
$ vncviewer localhost:1
 
  
Using different ports on the server/client:
+
{{Tip|It is possible, with a one-liner, to keep the port forwarding active during the connection and close it right after:
  $ vncviewer localhost:8900
+
  {{bc|$ ssh -fL 9901:localhost:5901 10.1.10.2 sleep 10; vncviewer localhost:9901}}
 +
What it does is that the {{ic|-f}} switch will make ssh go in the background, it will still be alive executing {{ic|sleep 10}}. vncviewer is then executed and ssh remains open in the background as long as vncviewer makes use of the tunnel. ssh will close once the tunnel is dropped which is the wanted behavior.}}
  
 
=== Connecting to a vncserver from Android devices over SSH ===
 
=== Connecting to a vncserver from Android devices over SSH ===
  
To connect to a VNC Server over SSH using an Android device:
+
To connect to a VNC server over SSH using an Android device as a client, consider having the following setup:
 +
# SSH running on the server
 +
# vncserver running on server (with {{ic|-localhost}} flag for security)
 +
# SSH client on the Android device: ''ConnectBot'' is a popular choice and will be used in this guide as an example
 +
# VNC client on the Android device: ''androidVNC'' used here
  
{{bc|1. SSH server running on the machine to connect to.
+
In ''ConnectBot'', connect to the desired machine. Tap the options key, select ''Port Forwards'' and add a port:
2. VNC server running on the machine to connect to. (Run server with -localhost flag as mentioned above)
+
Type: Local
3. SSH client on the Android device (ConnectBot is a popular choice and will be used in this guide as an example).
+
Source port: 5901
4. VNC client on the Android device (androidVNC).}}
+
Destination: 127.0.0.1:5901
  
Consider some dynamic DNS service for targets that do not have static IP addresses.
+
In ''androidVNC'' connect to the VNC port, this is the local address following the SSH connection:
 +
Password: the vncserver password
 +
Address: 127.0.0.1
 +
Port: 5901
  
In ConnectBot, type in the IP and connect to the desired machine. Tap the options key, select Port Forwards and add a new port:
+
== Tips and tricks ==
 +
=== Connecting to an OSX system ===
 +
See https://help.ubuntu.com/community/AppleRemoteDesktop. Tested with Remmina.
  
{{bc|Nickname: vnc
+
=== Connecting to non-X environments on a Raspberry Pi (Arch ARM) ===
Type: Local
+
Install {{AUR|dispmanx_vnc}} on the Arch ARM device. Frame rates are not very high but it provides a working VNC access.
Source port: 5901
 
Destination: 127.0.0.1:5901}}
 
  
Save that.
+
=== Recommended security settings ===
 +
If not [[#Accessing vncserver via SSH tunnels]] where the identification and the encryption are handled via SSH, it is recommended to use ''X509Vnc'', as ''TLSVnc'' lacks identity verification.
  
In androidVNC:
+
$ vncserver -x509key ''/path/to/key.pem'' -x509cert ''/path/to/cert.pem'' -SecurityTypes X509Vnc :1
  
{{bc|Nickname: nickname
+
Issuing x509 certificates is beyond the scope of this guide. However, [[wikipedia:Let's Encrypt|Let's Encrypt]] provides an easy way to do so. Alternatively, one can issue certificates using [[OpenSSL]], share the public key with the client and specify it with the {{ic|-X509CA}} parameter. An example is given below the server is running on 10.1.10.2:
Password: the password used to set up the VNC server
+
$ vncviewer 10.1.10.2 -X509CA ''/path/to/cert.pem''
Address: 127.0.0.1 (we are in local after connecting through SSH)
 
Port: 5901}}
 
  
Connect.
+
=== Starting X (startx) with vncserver ===
 +
Users invoking {{ic|startx}} to load the DE, should note that the default {{ic|~/.vnc/xstartup}} will launch an X session with {{ic|twm}} as the desktop ignoring the setting at the end of {{ic|~/.vnc/xstartup}}. Instead of specifying the desktop at the end of {{ic|~/.vnc/xstartup}}, {{ic|source}} {{ic|.xinitrc}} (with full path).
  
== Tips and tricks ==
+
=== Toggling Fullscreen ===
=== Connecting to an OSX system ===
+
This can be done through vnc client's Menu. By default, vnc client's Menu Key is F8.
  
See https://help.ubuntu.com/community/AppleRemoteDesktop. Tested with Remmina.
+
== Troubleshooting ==
 +
=== Unable to type '<' character ===
 +
If pressing {{ic|<}} on a remote client emits the {{ic|>}} character, try remapping the incoming key [https://insaner.com/blog/2013/05.html#20130422063137]:
  
=== Copying clipboard contents from the remote machine to the local ===
+
$ x0vncserver -RemapKeys="0x3c->0x2c"
 
 
If copying from the remote machine to the local machine does not work, run autocutsel on the server, as mentioned below [https://bbs.archlinux.org/viewtopic.php?id=101243 reference]:
 
  
  $ autocutsel -fork
+
=== Black rectangle instead of window ===
 +
Most probably this is due to the application strictly requiring the composite Xorg extension. For example webkit based app: midori, psi-plus, etc.
  
Now press F8 to display the VNC menu popup, and select {{ic|Clipboard: local -> remote}} option.
+
Restart vncserver in this case using something like following:
  
One can put the above command in {{ic|~/.vnc/xstartup}} to have it run automatically when vncserver is started.
+
  vncserver -geometry ... -depth 24 :1 +extension Composite
  
=== Fix for no mouse cursor ===
+
It looks like Composite extension in VNC will work only with 24bit depth.
  
 +
=== No mouse cursor ===
 
If no mouse cursor is visible when using {{ic|x0vncserver}}, start vncviewer as follows:
 
If no mouse cursor is visible when using {{ic|x0vncserver}}, start vncviewer as follows:
  
Line 307: Line 315:
 
Or put {{ic|DotWhenNoCursor<nowiki>=</nowiki>1}} in the tigervnc configuration file, which is at {{ic|~/.vnc/default.tigervnc}} by default.
 
Or put {{ic|DotWhenNoCursor<nowiki>=</nowiki>1}} in the tigervnc configuration file, which is at {{ic|~/.vnc/default.tigervnc}} by default.
  
=== Recommended security settings ===
+
=== Copying clipboard content from the remote machine ===
{{Note|If using ssh tunnels (i.e. [[#Accessing vncserver via SSH tunnels]]), X509Vnc is not required since the encryption is handled by the sshd.}}
+
If copying from the remote machine to the local machine does not work, run {{ic|autocutsel}} on the server, as mentioned in [https://bbs.archlinux.org/viewtopic.php?id=101243]:
  
SecurityTypes controls the preferred security algorithms. The default in the current version 1.5.0 is "X509Plain,TLSPlain,X509Vnc,TLSVnc,X509None,TLSNone,VncAuth,None". A more secure alternative is "X509Vnc,TLSVnc", which will disable all unencrypted data traffic.
+
$ autocutsel -fork
  
It is recommended to use X509Vnc, as TLSVnc lacks identity verification.
+
Now press F8 to display the VNC menu popup, and select {{ic|Clipboard: local -> remote}} option.
  
$ vncserver -x509key /path/to/key.pem -x509cert /path/to/cerm.pem -SecurityTypes X509Vnc :1
+
One can put the above command in {{ic|~/.vnc/xstartup}} to have it run automatically when vncserver is started.
 
 
Issuing x509 certificates is beyond the scope of this guide. However, this is expected to be straightforward after the public launch of [[wikipedia:Let's Encrypt|Let's Encrypt]]. Alternatively,  one can issue certificates using [[OpenSSL]] and manually share the keys between server and client using email for instance.
 
 
 
=== Toggling Fullscreen ===
 
  
This can be done through vncclient's Menu. By default, vncclient's Menu Key is F8.
+
=== "Authentication is required to create a color managed device" dialog when launching GNOME 3 ===
 +
A workaround is to create a "vnc" group and add the gdm user and any other users using vnc to that group.
 +
Modify {{ic|/etc/polkit-1/rules.d/gnome-vnc.rules}} with the following[https://github.com/TurboVNC/turbovnc/issues/47]:
  
=== Unable to type less than character (<) ===
+
    polkit.addRule(function(action, subject) {
If pressing {{ic|<}} on a remote client emits the {{ic|>}} character, try remapping the incoming key [https://insaner.com/blog/2013/05.html#20130422063137]:
+
      if ((action.id == "org.freedesktop.color-manager.create-device" ||
 +
            action.id == "org.freedesktop.color-manager.create-profile" ||
 +
            action.id == "org.freedesktop.color-manager.delete-device" ||
 +
            action.id == "org.freedesktop.color-manager.delete-profile" ||
 +
            action.id == "org.freedesktop.color-manager.modify-device" ||
 +
            action.id == "org.freedesktop.color-manager.modify-profile") &&
 +
          subject.isInGroup("vnc")) {
 +
          return polkit.Result.YES;
 +
      }
 +
    });
  
$ x0vncserver -RemapKeys="0x3c->0x2c"
+
== See also ==
 +
* https://github.com/TigerVNC/tigervnc

Latest revision as of 17:55, 9 October 2019

TigerVNC is an implementation of the Virtual Network Computing (VNC) protocol. This article focuses on the server functionality.

Installation

Install the tigervnc package.

Two VNC servers are available with TigerVNC:

  1. Xvnc is the default and recommended server for TigerVNC. It is both a VNC server and an X server with a virtual framebuffer. This means it is similar to the standard X server but has a virtual screen rather than a physical one. The virtual server runs in parallel with the physical X server should one be running. vncserver is a wrapper script which eases the starting of Xvnc. See #Running vncserver for virtual (headless) sessions for more information.
  2. x0vncserver provides direct control of the local X session(s) which are running on the physical monitor. It continuously polls the X display which is a simple but inefficient implementation. See #Running x0vncserver to directly control the local display for more information.

TigerVNC also provides vncviewer which is a client viewer for VNC.

Running vncserver for virtual (headless) sessions

Create password, startup and config files

The first time vncserver is run, it creates its initial environment, config, and user password file. These will be stored in ~/.vnc which will be created if not present. See vncserver(1) for the complete manual.

$ vncserver
You will require a password to access your desktops.

Password:
Verify:

New 'mycomputer:1 (theusername)' desktop is mycomputer:1

Creating default startup script /home/theusername/.vnc/xstartup
Starting applications specified in /home/theusername/.vnc/xstartup
Log file is /home/theusername/.vnc/mycomputer:1.log

Note the :1 trailing the hostname in the output messages of the script. This indicates the TCP port number on which the virtual VNC server is running. In this case, :1 is actually TCP port 5901 (5900+1). Running vncserver a second time will create a second instance running on the next highest, free port, i.e 5902 (5900+2) which shall end in :2 as above.

Note: Linux systems can have as many VNC servers as memory allows, all of which will be running in parallel to each other.

To shutdown the just created VNC server, use the -kill switch:

$ vncserver -kill :1

If at any stage one needs to change the previously defined password, the vncpasswd tool can be called:

$ vncpasswd

See vncpasswd(1) for more information.

Edit the startup script

The ~/.vnc/xstartup script is sourced by vncserver for creating the virtual X session and it must be adapted to one's needs. It functions like an .xinitrc file. In this script, users are expected to start a Desktop environment, see: General recommendations#Desktop environments.

For example, to start Xfce, the following script can be used:

~/.vnc/xstartup
#!/bin/sh
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
exec startxfce4
Note: The instruction unset DBUS_SESSION_BUS_ADDRESS clears the variable and forces startxfce4 to initiate a new bus for the VNC session. If D-Bus fails to start, try using exec dbus-launch startxfce4 instead to launch the bus manually, note that this latter way of starting D-Bus is deprecated.

To start GNOME, replace exec startxfce4 by exec dbus-launch gnome-session in the example above.

To start Cinnamon, replace exec startxfce4 by exec dbus-launch cinnamon-session in the example above.

Make sure ~/.vnc/xstartup has a execute permission.

Edit the optional config file

vncserver supports parsing parameters through the command line, or in the file ~/.vnc/config. The format of the config file is one option per line, option names are case-insensitive and commenting with # is supported. The parameters can be either vncserver specific or can be parameters that are passed to Xvnc, see vncserver(1) or Xvnc(1) for the full list of available options.

An example is provided below:

~/.vnc/config
securitytypes=tlsvnc
desktop=sandbox
geometry=1200x700
dpi=96
localhost
alwaysshared

Starting and stopping vncserver via systemd

Systemd can manage the vncserver by either running it in system or in user mode. Both ways are presented below.

User mode

The user mode is the most straightforward way to run the VNC server as a service. Start and enable vncserver@:1.service in Systemd/User mode, i.e. with the --user parameter. The :1 option can be replaced by another display number, it is the increment over 5900 the VNC server listens to. In the previous example, one connects to the server through port 5901.

Note: The vncserver will get killed when the user logs off the machine, see Systemd/User#Automatic start-up of systemd user instances for related configuration.

System mode

Create /etc/systemd/system/vncserver@:1.service. As in user mode above, :1 is the port increment over 5900 to which the VNC server will be listening for connections (e.g vncserver@:5.service means the server will be listening to port 5905). Edit the service unit by defining the user (User=) to run the server, and the desired vncserver options.

/etc/systemd/system/vncserver@:1.service
[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target

[Service]
Type=simple
User=foo
PAMName=login
PIDFile=/home/%u/.vnc/%H%i.pid
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/usr/bin/vncserver %i -geometry 1440x900 -alwaysshared -fg
ExecStop=/usr/bin/vncserver -kill %i

[Install]
WantedBy=multi-user.target

Start vncserver@:1.service and optionally enable it to run at boot time/shutdown.

On demand multi-user mode

One can use systemd socket activation in combination with XDMCP to automatically spawn VNC servers for each user who attempts to login, so there is no need to set up one server/port per user. This setup uses the display manager to authenticate users and login, so there is no need for VNC passwords. The downside is that users cannot leave a session running on the server and reconnect to it later.

To get this running, first set up XDMCP and make sure the display manager is running. Then create:

/etc/systemd/system/xvnc.socket
[Unit]
Description=XVNC Server

[Socket]
ListenStream=5900
Accept=yes

[Install]
WantedBy=sockets.target
/etc/systemd/system/xvnc@.service
[Unit]
Description=XVNC Per-Connection Daemon

[Service]
ExecStart=-/usr/bin/Xvnc -inetd -query localhost -geometry 1920x1080 -once -SecurityTypes=None
User=nobody
StandardInput=socket
StandardError=syslog

Use systemctl to start and enable xvnc.socket. Now any number of users can get unique desktops by connecting to port 5900.

If the VNC server is exposed to the internet, add the -localhost option to Xvnc in xvnc@.service (note that -query localhost and -localhost are different switches) and follow #Accessing vncserver via SSH tunnels. Since we only select a user after connecting, the VNC server runs as user nobody and uses Xvnc directly instead of the vncserver script, so any options in ~/.vnc are ignored. Optionally, autostart vncconfig so that the clipboard works (vncconfig exits immediately in non-VNC sessions). One way is to create:

/etc/X11/xinit/xinitrc.d/99-vncconfig.sh
#!/bin/sh
vncconfig -nowin &

Running x0vncserver to directly control the local display

As mentioned in #Installation, the tigervnc package also provides the x0vncserver binary which allows direct control over a physical X session. After defining a session password using the vncpasswd tool, invoke the server like so:

$ x0vncserver -rfbauth ~/.vnc/passwd

For more information, see x0vncserver(1).

Note: x0vncserver is an inefficient VNC server which continuously polls any X display, allowing it to be controlled via VNC. It is intended mainly as a demonstration of a simple VNC server. x11vnc is an alternative more advanced VNC server which also provides direct control of the current X session.

Starting x0vncserver via xprofile

A simple way to start x0vncserver is adding a line in one of the xprofile files such as:

~/.xprofile
...
x0vncserver -rfbauth ~/.vnc/passwd &

Starting and stopping x0vncserver via systemd

In order to have a VNC Server running x0vncserver, which is the easiest way for most users to quickly have remote access to the current desktop, create a systemd unit as follows replacing the user and the options with the desired ones:

~/.config/systemd/user/x0vncserver.service
[Unit]
Description=Remote desktop service (VNC)

[Service]
Type=simple
# wait for Xorg started by ${USER}
ExecStartPre=/bin/sh -c 'while ! pgrep -U "$USER" Xorg; do sleep 2; done'
ExecStart=/usr/bin/x0vncserver -rfbauth %h/.vnc/passwd
# or login with your username & password
#ExecStart=/usr/bin/x0vncserver -PAMService=login -PlainUsers=${USER} -SecurityTypes=TLSPlain

[Install]
WantedBy=default.target

Start and enable the service x0vncserver.service in Systemd/User mode, i.e. with the --user parameter.

Connecting to vncserver

Warning: The default's TigerVNC security method is not secure, it lacks identity verification and will not prevent man-in-the-middle attack during the connection setup. Make sure you understand the security settings of your server and do not connect insecurely to a vncserver outside of a trusted LAN.
Note: By default, TigerVNC uses the TLSVnc authentication/encryption method unless specifically instructed via the SecurityTypes parameter. With TLSVnc, there is standard VNC authentication and traffic is encrypted with GNUTLS but the identity of the server is not verified. TigerVNC supports alternative security schemes such as X509Vnc that combines standard VNC authentication with GNUTLS encryption and server identification, this is the recommended mode for a secure connection. When SecurityTypes on the server is set to a non-encrypted option as high-priority (such as None, VncAuth, Plain, TLSNone, TLSPlain, X509None, X509Plain); which is ill-advised, then it is not possible to use encryption. When running vncviewer, it is safer to explicitly set SecurityTypes and not accept any unencrypted traffic. Any other mode is to be used only when #Accessing vncserver via SSH tunnels.

Any number of clients can connect to a vncserver. A simple example is given below where vncserver is running on 10.1.10.2 port 5901, or :1 in shorthand notation:

$ vncviewer 10.1.10.2:1

Passwordless authentication

The -passwd switch allows one to define the location of the server's ~/.vnc/passwd file. It is expected that the user has access to this file on the server through SSH or through physical access. In either case, place that file on the client's file system in a safe location, i.e. one that has read access ONLY to the expected user.

$ vncviewer -passwd /path/to/server-passwd-file

The password can also be provided directly.

Note: The password below is not secured; anyone who can run ps on the machine will see it.
$ vncviewer -passwd <(echo MYPASSWORD | vncpasswd -f)

Example GUI-based clients

TigerVNC's vncviewer also has a simple GUI when run without any parameters:

$ vncviewer

Accessing vncserver via SSH tunnels

For servers offering SSH connection, an advantage of this method is that it is not necessary to open any other port than the already opened SSH port to the outside, since the VNC traffic is tunneled through the SSH port.

On the server

On the server side, vncserver or x0vncserver must be run.

When running vncserver, it is recommended to use the -localhost switch way since it allows connections from the localhost only and by analogy, only from users ssh'ed and authenticated on the box. For example run a command such as:

$ vncserver -geometry 1440x900 -alwaysshared -dpi 96 -localhost :1

For x0vncserver, this -localhost switch is not available but a workaround is to use the -HostsFile option and create the below file that will be provided as a parameter:

~/.vnc/hostsfile
+127.0.0.1
+::1
-

It will only accept connection from localhost in IPv4 or IPv6 address standard.

The corresponding command is:

$ x0vncserver -HostsFile ~/.vnc/hostsfile -SecurityTypes none

On the client

The VNC server has been setup on the remote machine to only accept local connections. Now, the client must open a secure shell with the remote machine (10.1.10.2 in this example) and create a tunnel from the client port, for instance 9901, to the remote server 5901 port. For more details on this feature, see OpenSSH#Forwarding other ports and ssh(1).

$ ssh 10.1.10.2 -L 9901:localhost:5901

Once connected via SSH, leave this shell window open since it is acting as the secured tunnel with the server. Alternatively, directly run SSH in the background using the -f option. On the client side, to connect via this encrypted tunnel, point the vncviewer to the forwarded client port on the localhost.

$ vncviewer localhost:9901

What happens in practice is that the vncviewer connects locally to port 9901 which is tunneled to the server's localhost port 5901. The connection is established to the right port within the secure shell.

Tip: It is possible, with a one-liner, to keep the port forwarding active during the connection and close it right after:
$ ssh -fL 9901:localhost:5901 10.1.10.2 sleep 10; vncviewer localhost:9901
What it does is that the -f switch will make ssh go in the background, it will still be alive executing sleep 10. vncviewer is then executed and ssh remains open in the background as long as vncviewer makes use of the tunnel. ssh will close once the tunnel is dropped which is the wanted behavior.

Connecting to a vncserver from Android devices over SSH

To connect to a VNC server over SSH using an Android device as a client, consider having the following setup:

  1. SSH running on the server
  2. vncserver running on server (with -localhost flag for security)
  3. SSH client on the Android device: ConnectBot is a popular choice and will be used in this guide as an example
  4. VNC client on the Android device: androidVNC used here

In ConnectBot, connect to the desired machine. Tap the options key, select Port Forwards and add a port:

Type: Local
Source port: 5901
Destination: 127.0.0.1:5901

In androidVNC connect to the VNC port, this is the local address following the SSH connection:

Password: the vncserver password
Address: 127.0.0.1
Port: 5901

Tips and tricks

Connecting to an OSX system

See https://help.ubuntu.com/community/AppleRemoteDesktop. Tested with Remmina.

Connecting to non-X environments on a Raspberry Pi (Arch ARM)

Install dispmanx_vncAUR on the Arch ARM device. Frame rates are not very high but it provides a working VNC access.

Recommended security settings

If not #Accessing vncserver via SSH tunnels where the identification and the encryption are handled via SSH, it is recommended to use X509Vnc, as TLSVnc lacks identity verification.

$ vncserver -x509key /path/to/key.pem -x509cert /path/to/cert.pem -SecurityTypes X509Vnc :1

Issuing x509 certificates is beyond the scope of this guide. However, Let's Encrypt provides an easy way to do so. Alternatively, one can issue certificates using OpenSSL, share the public key with the client and specify it with the -X509CA parameter. An example is given below the server is running on 10.1.10.2:

$ vncviewer 10.1.10.2 -X509CA /path/to/cert.pem

Starting X (startx) with vncserver

Users invoking startx to load the DE, should note that the default ~/.vnc/xstartup will launch an X session with twm as the desktop ignoring the setting at the end of ~/.vnc/xstartup. Instead of specifying the desktop at the end of ~/.vnc/xstartup, source .xinitrc (with full path).

Toggling Fullscreen

This can be done through vnc client's Menu. By default, vnc client's Menu Key is F8.

Troubleshooting

Unable to type '<' character

If pressing < on a remote client emits the > character, try remapping the incoming key [1]:

$ x0vncserver -RemapKeys="0x3c->0x2c"

Black rectangle instead of window

Most probably this is due to the application strictly requiring the composite Xorg extension. For example webkit based app: midori, psi-plus, etc.

Restart vncserver in this case using something like following:

 vncserver -geometry ... -depth 24 :1 +extension Composite

It looks like Composite extension in VNC will work only with 24bit depth.

No mouse cursor

If no mouse cursor is visible when using x0vncserver, start vncviewer as follows:

$ vncviewer DotWhenNoCursor=1 <server>

Or put DotWhenNoCursor=1 in the tigervnc configuration file, which is at ~/.vnc/default.tigervnc by default.

Copying clipboard content from the remote machine

If copying from the remote machine to the local machine does not work, run autocutsel on the server, as mentioned in [2]:

$ autocutsel -fork

Now press F8 to display the VNC menu popup, and select Clipboard: local -> remote option.

One can put the above command in ~/.vnc/xstartup to have it run automatically when vncserver is started.

"Authentication is required to create a color managed device" dialog when launching GNOME 3

A workaround is to create a "vnc" group and add the gdm user and any other users using vnc to that group. Modify /etc/polkit-1/rules.d/gnome-vnc.rules with the following[3]:

   polkit.addRule(function(action, subject) {
      if ((action.id == "org.freedesktop.color-manager.create-device" ||
           action.id == "org.freedesktop.color-manager.create-profile" ||
           action.id == "org.freedesktop.color-manager.delete-device" ||
           action.id == "org.freedesktop.color-manager.delete-profile" ||
           action.id == "org.freedesktop.color-manager.modify-device" ||
           action.id == "org.freedesktop.color-manager.modify-profile") &&
          subject.isInGroup("vnc")) {
         return polkit.Result.YES;
      }
   });

See also