(I am not looking for answers such as "Stop using VNC as it is insecure", nor do I need answers recommending different VNC implementations, as I'm specifically wanting to get TigerVNC to function properly).
I need to display and control a Ubuntu 18.10 desktop from an Ubuntu 18.10 laptop, using TigerVNC. Both machines have been upgraded to 18.10 recently.
I have enabled desktop sharing on the desktop via the instructions in https://askubuntu.com/a/1088328 with with this exception: When I have not executed the following command:
gsettings set org.gnome.Vino require-encryption false
it does not work (see below). But when I do use that gsettings
command on the desktop, then I to get a prompt for the vnc password,
and upon typing it in, I'm able to control the desktop. So
ultimately, I know that must be the fix, but I specifically need to
know why that would be required (see remmina usage below). None of my
web searches have provided an answer of why.
On the desktop machine, the Sharing settings are:
Note: I can successfully use the remmina tool, using the VNC setting,
to connect to the desktop machine and display it, without using the
above gsettings setting on the desktop machine. But, when I use the
TigerVNC type of vncviewer using this command:
vncviewer thedesk.local:0
(where thedesk.local is the Ubuntu desktop machine), I get a popup with:
No matching security types
And the output into the shell shows:
$ vncviewer thedesk.local:0
TigerVNC Viewer 64-bit v1.9.0
Built on: 2018-07-29 13:31
Copyright (C) 1999-2018 TigerVNC Team and many others (see README.rst)
See http://www.tigervnc.org for information on TigerVNC.
Sun May 26 07:10:29 2019
DecodeManager: Detected 8 CPU core(s)
DecodeManager: Creating 4 decoder thread(s)
Sun May 26 07:10:30 2019
CConn: connected to host thedesk.local port 5900
Sun May 26 07:10:31 2019
CConnection: Server supports RFB protocol version 3.7
CConnection: Using RFB protocol version 3.7
CConnection: No matching security types
CConn: No matching security types
On both the Ubuntu 18.10 laptop and the desktop machines, I have these
installed versions of vnc-like packages, apt remove-ing all other
flavors of "vnc" clients/servers to avoid confusion with the
Linux "alternatives" mechanism:
$ dpkg --list *vnc* | grep '^i'
ii libvncclient1:amd64 0.9.11+dfsg-1.1ubuntu0.1 amd64 API to write one's own VNC server - client library
ii remmina-plugin-vnc:amd64 1.2.31.4+dfsg-1ubuntu1 amd64 VNC plugin for Remmina
ii tigervnc-common 1.9.0+dfsg-1 amd64 Virtual network computing; Common software needed by servers
ii tigervnc-standalone-server 1.9.0+dfsg-1 amd64 Standalone virtual network computing server
ii tigervnc-viewer 1.9.0+dfsg-1 amd64 Virtual network computing client for X
$ vncviewer --version |& head -5
TigerVNC Viewer 64-bit v1.9.0
Built on: 2018-07-29 13:31
Copyright (C) 1999-2018 TigerVNC Team and many others (see README.rst)
See http://www.tigervnc.org for information on TigerVNC.
$
remmina --version pops up with a dialog that reads:
1.2.31.4 (git n/a)
The reason remmina is involved is just to show that some client is able to talk to the Ubuntu desktop, just not TigerVNC. I've tried connecting to thedesk.local from a Raspberry Pi 3 B+ running Raspbian and got a different error, but still seemingly involving a similar incompatibility with security protocols between VNC implementations. The error is:
So, what is remmina providing to the X server (or VNC server?) running on display :0 on thedesk.local, that the TigerVNC viewer client (or that RealVNC client running under Raspbian) is not providing?
My web searches turn up results such as
https://ubuntuforums.org/showthread.php?t=2384046 which give "Why
don't you do 'X' instead?" type of responses, which is a fair
observation. But I specifically want to find out why I would have to
use the gsettings change just to get TigerVNC viewer to popup the
prompt, while remmina does not require it. (When I need to have
security, I know how to tunnel traffic over SSH already.)
Apparently there are two completely different encryption protocols available for VNC. According to "Network Security Assessment: Know Your Network", Table 7-31 there are:
(not sure why the book explicitly mentioned "Ubuntu" for type 18 here).
Vino (the Gnome desktop sharing application) uses LibVNCServer as backend. And LibVNCServer only supports type 18. Remmina uses LibVNCServer as well, therefore it also supports type 18. By the way since Remmina is a VNC client, I guess it even supports type 19.
TigerVNC on the other hand apparently does not support type 18 but does support type 19; at least that's what the source code suggests.
The reason why the two tools can actually communicate after
gsettings set org.gnome.Vino require-encryption falseis that this command switches off encryption in Vino, so TigerVNC will just use an unencrypted connection (which is a protocol that both tools support).To really fix this, either LibVNCServer needs to add support for type 19 (VeNCrypt), or TigerVNC needs to add support for type 18. I don't know if there's any such efforts under way on either project.
Side note: I guess this whole situation is made much more complicated by the fact that these two schemes are both kinda called "TLS" and do actually use TLS underneath, but are still incompatible. And for type 18 there's not even an actual name; and type 19/VeNCrypt itself has nine different subtypes for different encryption methods. In my experience this entire mess is very representative of the VNC protocol.
2 month old thread, so you might've found the answer already.
Native VNC sharing working on stock Ubuntu 18.04 LTS
gsettings set org.gnome.Vino require-encryption false2022 update:
Vino has been renamed gnome-remote-desktop and it's been included in Ubuntu since focal (20.04). The new location in gsettings has been changed and the new setting to disable encryption is
gsettings set org.gnome.desktop.remote-desktop.vnc encryption \[\'none\'\]Supporting the answer by oliver, if I run
/usr/lib/vino/vino-server &from the CLI (in terminal #1), all output is seen there. Then executinggsettings set org.gnome.Vino require-encryption falsefrom another terminal (#2) produced the following output in #1: