VNC accessible from non-linux machines only with encryption disabled

[Romano Giannetti]

Since a recent update, it is impossible to connect to my Ubuntu box using VNC from a Windows machine unless I disable encryption on the vino server.

I tested up-to-date tightVNC client and TigerVNC client on the Windows machine, with the same result. As soon I try to connect, I receive the following error:

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

So it seems that the update changed the security type of vino to a new one. I searched for a way to go back to the old one (until the clients catches up) with no avail.

A solution is disabling the encryption completely, by

gsettings set org.gnome.Vino require-encryption false

...but this is subotpimal. Is there a way to switch the encryption back to the old one?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Sebastien Bacher (seb128)]

Thank you for your bug report. Not sure if that's a bug or just increased security config by default. It might mean that you should fix your client to use a secure correction...

[Romano Giannetti (romano-giannetti)]

I agree that the best possible solution would be for the Windows clients (at least TigerVNC and TightVNC) to catch up. Unfortunately this has not happened; for the time being it would be much better if vino could offer the option to go back to the previous Security Type when the client does not support the new one.

The only solution now is disable the encryption completely; I resorted to a loop back ssh connection so that there is no clear traffic on the wifi, but I still need to do the local step with vino in clear way --- almost safe for me because I do not have other local users, but you never know...

[Sebastien Bacher (seb128)]

Did the security level change or was the old default to accept unsecure login (which seems a buggy default)?

[Romano Giannetti (romano-giannetti)]

I reported the thing to TigerVNC bug tracker too: https://sourceforge.net/p/tigervnc/bug-tracker/148/ let's see if a solution can be found...

[Romano Giannetti (romano-giannetti)]

Sebastian: no. the default is to use encryption. But after updating vino (do not remember at which point), vino changed the security type to a new one (at least, I think); the connection stopped to work with the error reported above and the only solution to have it back was to disable encryption.

What I *suppose* happened is that the vino server upgraded the encryption algorithm and the clients have still to catch up; the problem is that there seems no way to say vino to use an old encryption --- it just works with the "type 18" or none.

[Sampo Savola (samposavola)]

Rmano, I dont think this is a duplicate: https://bugs.launchpad.net/ubuntu/+source/vino/+bug/1307084

If you read my bug raport...I disabled the encryption with dconf trick but still it didnt work from Mac OSX Screen Sharing application. Dconf trick makes other vnc clients work such as TightVNC but only solution for Mac OSX Screen Sharing to work was to build older Vino-server from 13.10.

[Sebastien Bacher (seb128)]

@Sampo: ok, unduplicated, please send upstream, we don't have macOS systems to test your specific issue

[Sebastien Bacher (seb128)]

The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

[Romano Giannetti (romano-giannetti)]

Ok, I have reported it upstream at

 https://bugzilla.gnome.org/show_bug.cgi?id=728267

--- but I am unable to add it to the bug. I used to choose älso affect distribution"and simply paste the URL, but now I have an error (says I can't add another bug to the same distribution and in the dsitribution lists there is no "gnome upstream to choose"). How am I supposed to add the upstream bug?

[Romano Giannetti (romano-giannetti)]

Can please people with the problem state their version? Mine is

[:~] 127 % apt-cache policy vino
vino:
  Installed: 3.10.0-0ubuntu1~saucy1
  Candidate: 3.10.0-0ubuntu1~saucy1
  Version table:
 *** 3.10.0-0ubuntu1~saucy1 0
        500 http://ppa.launchpad.net/gnome3-team/gnome3-staging/ubuntu/ saucy/main i386 Packages
        100 /var/lib/dpkg/status
     3.6.2-0ubuntu5 0
        500 http://archive.ubuntu.com/ubuntu/ saucy/main i386 Packages

Anyone with stock 3.8 version?

[Sebastien Bacher (seb128)]

Upstream comment

"I guess that the problem occurs after the default was changed to require encryption:

https://git.gnome.org/browse/vino/commit/?id=f37ca213fda500ea2f93d005e945644c2f2e5721

For whatever reason, that fails with some clients. If you want Vino to work
with those clients new authentication types need to be added. There is some
information about the protocol and security types at:

http://sourceforge.net/p/tigervnc/code/HEAD/tree/rfbproto/rfbproto.rst

I will not have time to add the security types in the near future."

[Romano Giannetti (romano-giannetti)]

Upstream comment:

"I think that the TLS security type (18) is rather uncommon, but gtk-vnc
supports it. I think that virt-viewer uses gtk-vnc and should work:

http://virt-manager.org/download/
"

so basically the problem is that vino is using an encryption type which is supported only by few clients. The optimal solution would be to help vino developers to add a more common encryption type; for the time being, I will test the suggested viewer and comment.

[Romano Giannetti (romano-giannetti)]

Well, downloaded it (virt-viewer, I mean). Tried to connect to a remote machine but no dice --- it just show a window, asking for a connection URI, I tried 200 combinations... No documentation handy available either. Seems to be thought just for managing virtual machines, so it doesn't seem a general VNC viewer tool.

So I think that the only option now is

a) having a VNC with almost no interoperability with Windows

or

b) re-defaulting to no encryption

Really, I do not know which one of the two options is the worst one.

[Holger Mauermann (mauermann)]

This doesn't affect only Windows, but Android too. I tried two different apps ("VNC Viewer" from RealVNC Limited and "Jump Desktop" from Phase Five Systems), but since upgrading my Ubuntu Desktop to Trusty both fail with error messages related to incompatible security types.

[Romano Giannetti (romano-giannetti)]

@Holger: yes --- I just noticed it too.

I humbly suggest that Canonical or Redhat help the vino developers to add a more common encryption type to the vino server. It is the default (and the facto only) remote vnc server in our system, and in its current state forces everyone to connect **in clear** on the local network. All what you type is sent as is.

I have worked around it wrapping the thing in a SSH tunnel, but still, it's sensible to local attacks and I think it's not a solution for the average user.

@Sebastian, I am not sure if this is a security thing --- after all, before the switch, all the connections were silently made without encryption, but it's scary nevertheless --- sniffing for traffic on port 5900 is easy enough.

[nitrogen dream (nitrogendream)]

Guys,

The problem is simple.
If you take a Wireshark trace you immediately see the issue.
You will have to filter on VNC.
The supported security type which is given for 14.04 is "type 18, TLS".
For 13.10 we see two types, "type 18, TLS" and "type 2, VNC".

The "type 2, VNC" is used by your VNC viewer.
So adding type 2 in the proposed supported security types will solve this bug.

[Plurtu (plurtu)]

Enhanced TightVNC Viewer (SSVNC) works with vino's ANONTLS encryption on Windows.

http://www.karlrunge.com/x11vnc/ssvnc.html

Don't expect to connect in a hurry though.

[Romano Giannetti (romano-giannetti)]

@nitrogen dream: reading here: https://sourceforge.net/p/tigervnc/code/HEAD/tree/rfbproto/rfbproto.rst#vnc-authentication, with type 2 the only thing that is encrypted is the VNC password, which is, honestly, my least worry. All the keystrokes in the session (including your bank password) is then sent unencrypted on the local wire.

Will check SSVNC; but this is similar to what I am doing now, having a ssh tunnel in the middle.

But again, the problem is in vino, which is offering as encrypted transport one that nobody uses --- and that force you to go thru hoops to have an almost safe connection.

[Romano Giannetti (romano-giannetti)]

SSVNC works, although is quite slow with vino. Using x11vnc as server with -ssl options give a reasonable speed.

[fabrizio croce (fabrizio-croce)]

Apologises, I am not a super expert but I suffer this VNC BUG after Ubuntu TLS 14.04 upgrade.

Unfortunately to me does not work dconf > desktop > gnome > remote-access > enabled - uncheck
 (it is unchecked but VNC continue do not work at Ubuntu reboot)

Only to set 'gsettings set org.gnome.Vino require-encryption false' manually works

is there any workaround to disable encription and remain disabled at reboot until this BUG is not fixed ?

Many Thanks

[monomakh (monomakh)]

I am confirm, that vino doesn't work after upgrade to 14.04 and gsettings set org.gnome.Vino require-encryption false doesnt helps to start vino server.

[fabrizio croce (fabrizio-croce)]

try in this way:

$ pkill vino
$ export DISPLAY=:0.0
$ /usr/lib/vino/vino-server &
$ gsettings set org.gnome.Vino require-encryption false

VNCclient you have to choose encryption off

[Kurt M. Sanger (ksanger)]

I too am having trouble connecting to Ubuntu 14.04 LTS, however we are trying to connect using Ubuntu 12.04 LTS. We've tried encryption off. We've tried Remina Remote Desktop Client, and Gtk Vnc Viewer. Bot VNC applications are able to login to the 14.04 box, however neither one of them will control anything. The remote screen does not update. Windows are imovable. Mouse clicks do not appear to work.

When using Remina Remote Desktop Client and encryption off you can see that sometimes the 14.04 screen has changed due to actions on the 12.04 remote session. For instance cntrl alt T opened a terminal session. However the remote screen on the 12.04 remote session does not update and the new terminal sessions were not shown remotely.

On the 14.04 box I have allow others to control your desktop checked through desktop sharing. I also have encryption off. We have tried killing vino, setting DISPLAY, restarting vino-server, and setting encryption off using gsettings. Also view-only is false.

[Kurt M. Sanger (ksanger)]

Today we tried the command gsettings set org.gnome.Vino disable-xdamage true, which also did not work. Then we wiped the hard drive and loaded Ubuntu 12.04 LTS. We could not remote into 12.04 LTS from 12.04 LTS using either Remmina Remote Desktop nor Gtk VNC Viewer until we first logged into the remote machine using 2D mode. Then the remote session updated the screen and enabled us to see our controlling of the remote PC.

Interestingly we then logged off and logged back into the remote PC in 3D mode and the remote connection still worked. Finally we rebooted the remote PC, logged in under 3D mode, and the remote connection still works. I have no idea what is different but logging in one time under 2D mode set something up correctly. Wish I had tried that on 14.04, however I'm not going back soon. Hopefully this will help you guys figure this out.

Currently the command gsettings get org.gnome.Vino disable-xdamage returns false on the remote PC.

[Wes Garner (wesgarner)]

FYI Solution for Android users - use bVNC Free
It accepts this encryption type

[Rudolf Reuter (reuterr)]

In case you boot with an USB-stick, it may be very difficult to get VNC running.

A quick workaround in the terminal, to make it work:
$ gsettings set org.gnome.Vino enabled true
$ gsettings set org.gnome.Vino require-encryption false

[Hrotkó Gábor (roti-al)]

On windows, I use SSVNC to connect to vino-server, and it works great.

[John Moser (nigelenki)]

It also resets the configuration every time you upgrade Ubuntu, so the work-around must be re-applied. Breaking a system's custom configuration when upgrading is probably bad juju.

[Peter Funk (pf-artcom-gmbh)]

Question: How can I apply "gsettings set org.gnome.Vino require-encryption false" in a ssh-session from remote?

[Jamshid Afshar (jafshar)]

Even after disabling encryption I cannot get OS X El Capitan to connect -- it asks for a password then spins. Using the Mac app Chicken of the VNC does work, though.

[Iordan Iordanov (iiordanov)]

The upstream bug was reported about 2.5 years ago. It certainly looks like the developers of Vino are not going to change the default to not require encryption. Would it be possible to change the default for Ubuntu to not require encryption at least?

[Varstamni Q (varstamni)]

Iordane (Dancho), it is not a bug at all. It is inconvenient for me too, but they are the developers of vnc clients for windows who do not do the appropriate thing (add TLS support or so). To have default behavior not to require encryption is a very bad idea basically. And you can disable it by hand at any time.

[Iordan Iordanov (iiordanov)]

Using a protocol that does not verify the identity of the server in
any way (AnonTLS that uses Anonymous Diffie Hellman ciphers) can be as
good as no encryption or worse, as it gives users a false sense of
security.

On Sun, Mar 5, 2017 at 11:25 AM, Varstamni Q <email address hidden> wrote:
> Iordane (Dancho), it is not a bug at all. It is inconvenient for me too,
> but they are the developers of vnc clients for windows who do not do the
> appropriate thing (add TLS support or so). To have default behavior not
> to require encryption is a very bad idea basically. And you can disable
> it by hand at any time.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1615251).
> https://bugs.launchpad.net/bugs/1281250
>
> Title:
> VNC accessible from non-linux machines only with encryption disabled
>
> Status in vino:
> Confirmed
> Status in vino package in Ubuntu:
> Triaged
> Status in vino source package in Trusty:
> Triaged
> Status in vino package in Fedora:
> Unknown
>
> Bug description:
> Since a recent update, it is impossible to connect to my Ubuntu box
> using VNC from a Windows machine unless I disable encryption on the
> vino server.
>
> I tested up-to-date tightVNC client and TigerVNC client on the Windows
> machine, with the same result. As soon I try to connect, I receive the
> following error:
>
> [ 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.
>
> So it seems that the update changed the security type of vino to a new
> one. I searched for a way to go back to the old one (until the clients
> catches up) with no avail.
>
> A solution is disabling the encryption completely, by
>
> gsettings set org.gnome.Vino require-encryption false
>
> ...but this is subotpimal. Is there a way to switch the encryption
> back to the old one?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/vino/+bug/1281250/+subscriptions

--
The conscious mind has only one thread of execution.

[Craig Hansen (craig-hansen)]

I've been trying to turn off encryption on vino-server in order to use one of many of the VNC clients that don't deal with TLS encryption. In the past, I've been able to start the vino-server by running by using "DISPLAY=:0 /usr/lib/vino/vino-server --sm-disable >& ~/.vino.log &" from a shell invoked with "ssh -X remotehostname".

The usual advice to turn off encryption and restart vino has reached yet another wrinkle: Upon attempting to restart vino-server (because the gsettings changes don't get re-read by vino-server except upon restart, already a problem), we now get the following messages (1) "(vino-server:21493): EggSMClient-CRITICAL **: egg_sm_client_set_mode: assertion 'global_client == NULL || global_client_mode == EGG_SM_CLIENT_MODE_DISABLED' failed" and (2) "** Message: The desktop sharing service is already running, exiting.", even after a "pkill vino".

Message (1) I haven't tracked down, though another bug report: https://bugs.launchpad.net/ubuntu/+source/vino/+bug/1082182 mentions essentially the same problem, but there's no resolution.

For message (2), looking at the source code, this message comes from name_lost(), which is called from:
g_bus_own_name (G_BUS_TYPE_SESSION, "org.gnome.Vino",
                  G_BUS_NAME_OWNER_FLAGS_NONE,
                  bus_acquired, name_acquired, name_lost,
                  &vino, NULL);

Now, looking at the doc for g_bus_own_name(), from https://developer.gnome.org/gio/stable/gio-Owning-Bus-Names.html

There are two ways the name_lost handler might be invoked: "You are guaranteed that one of the name_acquired_handler and name_lost_handler callbacks will be invoked after calling this function - there are three possible cases:
name_lost_handler with a NULL connection (if a connection to the bus can't be made).
bus_acquired_handler then name_lost_handler (if the name can't be obtained)
bus_acquired_handler then name_acquired_handler (if the name was obtained)."

Unfortunately the writer of this name_lost code assumed that it must be because of the second case, and completely ignored the first case (if a connection to the bus can't be made), making it hard to distinguish what's going wrong here. I know that when, for example, starting emacs from the command line over an "ssh -X" connection, I get a bunch of error messages about having trouble connecting to dbus, but it eventually starts up. Is this something similar, except that gives up immediately?

I've been unable to figure out how to restart the vino-server in these cases, other than to reboot the machine. Is there a any better way to restart the vino-server?

A final thought - is there any possibility of (a) turning off require encryption by default or (b) having vino-preferences set up to click off the option of requiring TLS encryption or (c) having some normal way to restart the vino-server (such as "sudo service vino restart" or something) or (d) having vino-server re-read the settings before opening a new connection or even (e) having a man page for vino-server? It's my understanding that this "require encryption" option only protects the initial handling of the password, and that all the rest of the session keystrokes and displa...

[Ken Howe (leggazoid)]

I use vino in ubuntu 16.04.3 LTS and the clients that work with encryption are vinagre and remmina.

[Noel Grandin (noelgrandin)]

Common guys. This bug is still present in Ubuntu18, and it makes for a truly lousy out-of-box experience.

Just turn encryption off by default.

The client should be the thing that wants encryption and asks for it.

[lystudio (lystudio)]

Hello, could anyone please try to fix this? It still impacts Ubuntu 18.04.2 LTS.

[Daniel Mladek (delphym)]

Hello, I can confirm this issue is still present on latest:
* Ubuntu 18.04.3 LTS (upgraded today)
When trying to connect from macOSX Mojave (10.14.6 (18G1012)
** its application "Screen Sharing v1.7.2(498.150)" or
** VNC® Connect Viewer v6.19.1115 (r42122) x64 (Nov 11 2019 12:05:05)

In both cases I am not able to connect to my Ubuntu desktop remotely thanks to this issue.
Following this advice: https://askubuntu.com/questions/463486/can-no-longer-use-screen-share-to-connect-mac-to-ubuntu-since-upgrading-to-14-04 by disabling Vino's security (require-encryption = OFF) I was able to connect from both clients.

Now, I'm getting warnings: "The connection to this VNC Server will not be encrypted."

When I'm connecting between two Ubuntu's 18.04 LTS or from Ubuntu to Mac, there has not been any issues.