(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:

Sharing settings on desktop

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                    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: (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:

rpi vnc attempt

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.)


2 month old thread, so you might've found the answer already.

Native VNC sharing working on stock Ubuntu 18.04 LTS

  • Enable Sharing
  • Set VNC PW
  • Set Firewall rule (or disable ufw entirely, depending on your use case)
  • Run this as logged in user (sudo not required) gsettings set org.gnome.Vino require-encryption false
  • 1
    I believe you missed the question I am asking. See the question starting with "what is remmina providing". Basically, I already know how to make it work, I want to know why I have to use that gsettings commands in the first place, when remina it doesn't require it. – bgoodr Jul 31 '19 at 19:47

Apparently there are two completely different encryption protocols available for VNC. According to "Network Security Assessment: Know Your Network", Table 7-31 there are:

- type 18: TLS authentication, used by Ubuntu Linux distributions
- type 19: TLS authentication, used by the Win32 VeNCrypt package

(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 false is 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.