The facts: I had a configuration for sharing my desktop that worked till the recent update of Gnome desktop to use sgnome-shell 3.10. I used to connect to my machine form a Windows one using TightVNC and it worked flawlessly till yesterday (2014-19-1).

Now the connection from the Windows side is failing (full log in pastebin) with this error:

tightvnc error

Which digging the log it is:

[ 5872/ 6448] 2014-01-20 12:11:18:247   List of security type is read
[ 5872/ 6448] 2014-01-20 12:11:18:247 : Security Types received (1): Unknown type (18)
[ 5872/ 6448] 2014-01-20 12:11:18:247   Selecting auth-handler
[ 5872/ 6448] 2014-01-20 12:11:18:247 + RemoteViewerCore. Exception: No security types supported. Server sent security types, but we do not support any of their.

The "sharing" part is configured as it should, as you can see here:


The diagnosis: It seems that the update changed the security type to a new one not known by tightVNC (it happened in the past).

The Question: until TightVNC (and the rest of the world) catches up, is it possible to configure the internal VNC server to use the previous Security Type?

4 Answers 4


Real solution: I am now using SSVNC on the windows machine and x11vnc on the linux server. Works with bVNC on android too. You need a bit of expertise to make it work, so terse instruction here:

On Linux (follow the instruction that x11vnc is giving you, is verbose but worth reading):

x11vnc -storepasswd
x11vnc -forever -repeat -usepw -ssl -autoport 6000 

(you will have to put the last one in one of your login startup scripts, or whatever. Do not use a passphrase on the generated SSL certificate. I am using port 6000 to not mess with vino).

On Windows: Install the binary client from here.

Connect and enjoy a (slowish...) encrypted connection.

Partial answer: (posted for sake of helping other people, NOT RECOMMENDED); I hope there will be other answers to the question --- I will mark this answer as the right one as there are no solution by now).

The problem surfaced when the Vino project decided to switch to require encryption by default --- unfortunately, the only kind of encryption supported by the vino server (type 18) is not supported by most of the Windows, Android, and iOS viewer. For what I know, only the Linux-based vinagre viewer supports it.

I have reported a bug to the Vino project, both upstream and in launchpad about this issue; look there for more details. Basically, it seems that there is no sufficient developer power to implement more encryption types to the server (fair enough).

That means that you can go back to the previous, unsafe behavior by disabling encryption for the whole VNC layer by using dconf-editor like this:

No Encryption for VNC

Big fat notice that means that all what you type is visible in clear in the network. Passwords included.

I can do it because the connection is really through an encrypted SSH tunnel and there are no other local users on the remote machine --- but even in this case, if someone manage to get access to your machine, they can read all your secrets by sniffing

  • 4
    If anyone else is looking for the key's location, it's under org»gnome»desktop»remote-access. Btw as soon as I changed this setting I could immediately connect to the box again. Feb 12, 2014 at 12:03
  • Yes, it works --- but the connection will be not encrypted on the line, password included, so use it only in very safe networks. Having the options to use an old encryption would be safer.
    – Rmano
    Feb 17, 2014 at 19:04

One liner UNSAFE encryption turn off command for 16.04

dconf write /org/gnome/desktop/remote-access/require-encryption false

then TigerVNC and realvnc work from Windows.

As Rmano pointed out however, only do this if your connection is already encrypted on another layer.

Found with dconf dump.

There is also a compatibility request on the TigerVNC side: https://github.com/TigerVNC/tigervnc/issues/307

  • Worked like a charm!
    – Luis
    Oct 30, 2017 at 1:24

Use SSH to secure the unencrypted VNC session...

Disable the client unsupported default encryption requirement

dconf write /org/gnome/desktop/remote-access/require-encryption false

Disable listening on the default interface, use lo (loopback)

dconf write /org/gnome/desktop/remote-access/network-interface lo

Windows has the necessary commands to generate SSH keys, copy the ssh id to the vnc-tunnel account, and setup a port forward.

Example SSH port forwarding command

ssh.exe -vvv -L 5900: -N -i %USERPROFILE%/.ssh/id_vnc [email protected]

  • Yes, but now another local user on the Linux machine can see the traffic from lo to the vino server unencrypted. If you are sure you are the only user on the Linux machine (can you? ) it's ok, and it's the solution I use --- read the last paragraph of my question.
    – Rmano
    Sep 2, 2021 at 5:58

Quickly locate location to edit - start dconf-editor, type ctl f - type 5900 - press enter and the proper area to disable encryption is displayed. If multiple sections have 5900, press next to find next occurrence.

  • Yes --- if you read my answer and the question carefully, you'll see that I know how to disable encryption. I am asking if it's possible to downgrade the security algorithm to the previous used one! This answer is basically the same than mine, I do not understand it.
    – Rmano
    Apr 6, 2014 at 1:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .