Created attachment 769989 [details]
Desktop Sharing Preferences
Description of problem:
In F19, you can't connect to vino with any vncviewer (tigervnc, realvnc), except with vinagre, because 'require-encryption' is always on. You can only changing the Value in dconf-editor and not in 'Desktop-Sharing Preferences'.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Setting up vino to accept connections
2. Connecting with any vncviewer will fail, except vinagre
3. Install and open dconf-editor, go to /org/gnome/desktop/remote-access and disable the value require-encryption.
4. Vncviewers will working again
This is exactly the same bug:
Created attachment 769993 [details]
This problem also exists when connecting using tigervnc on both systems. On my system with xfce and no gnome the circumvention cannot be used.
Confirming Erik's observation. Attempting to connect to Windows machine running identical version of TigerVNC (server) via TigerVNC (client) on Fedora 19 with all Encryption and Authentication methods enabled, including:
- TLS with anonymous certificates
- TSL with X509 certificates
- Standard VNC (insecure without encryption)
- Username and password (insecure without encryption)
yields the following:
TigerVNC Viewer 64-bit v1.3.0 (20130712)
Built on Jul 12 2013 at 11:52:21
Copyright (C) 1999-2011 TigerVNC Team and many others (see README.txt)
See http://www.tigervnc.org for information on TigerVNC.
Tue Jul 23 10:26:56 2013
CConn: connected to host host.hostname.com port 5900
CConnection: Server supports RFB protocol version 3.8
CConnection: Using RFB protocol version 3.8
CConnection: No matching security types
CConn: No matching security types
I confirm that vino-22.214.171.124.fc19.x86_64 server doesn't work, as described above (on a fresh F19 3.10.5-201 installation running Gnome).
Rather surprised given the above comments & my recent experiences with Fedora that replacing vino with tigervnc-server-1.3.0-3 worked straight away, using both RealVNC & TigerVNC clients from Windows 8. The connection info shows that there's no encryption (it's set to let the server choose - it fails to connect when encryption is enforced).
finding I need to add "-SecurityTypes VncAuth" to a bunch of scripts under f19 that worked previously with vncviewer. These all get ssh tunneled, so there's no actual security issue for me.
This bug is not fixed in F20. Changing version to 20.
I'm seeing this as well on Fedora 20 - enabled screen sharing from Gnome control cente. Any client on OS X I try (native, VNCViewer, JollyFastVNC) disconnect immediately (I've ensured the port is open).
Thanks, the solution worked for me with dconf-editor settings.
for me the solution with dconf-editor did not work in fedora 20 had to use the following command:
gconftool-2 -s -t bool /desktop/gnome/remote_access/required-encryption false
So every time I moved in with dconf parameter options were put on the settings present in gconf.
I've checked this can set require-encryption value to false.
gsettings set org.gnome.Vino require-encryption false
Reported upstream at https://bugzilla.gnome.org/show_bug.cgi?id=728267
It seems that the problem is that vino support a type of encryption which is almost nowhere implemented in viewers: https://bugzilla.gnome.org/show_bug.cgi?id=728267#c3 and https://bugzilla.gnome.org/show_bug.cgi?id=728267#c6
That means that most of the connections via VNC to our desktops from Windows, Android and iOS devices will be unencrypted --- all what you type is transmitted *in the clear*. Unless you use a ssh tunnel.
I really recommend bumping the severity of this bug, and to help the vino developers to add a more common supported encryption type.
*** This bug has been marked as a duplicate of bug 987981 ***