Ubuntu – Gnome 3.10 sharing desktop — how to configure the security type for VNC

gnomevnc

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:

sharing-settings

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?

Best Answer

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

Related Question