Bug 981984 - Can't connect to Vino, except with Vinagre
Summary: Can't connect to Vino, except with Vinagre
Status: CLOSED DUPLICATE of bug 987981
Alias: None
Product: Fedora
Classification: Fedora
Component: vino   
(Show other bugs)
Version: 20
Hardware: Unspecified Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: David King
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-07 14:13 UTC by Steve
Modified: 2016-08-10 18:31 UTC (History)
25 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-01-12 14:50:50 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Desktop Sharing Preferences (3.86 MB, image/png)
2013-07-07 14:13 UTC, Steve
no flags Details
dconf Editor (3.86 MB, image/png)
2013-07-07 14:14 UTC, Steve
no flags Details

Description Steve 2013-07-07 14:13:03 UTC
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):
vino-3.8.1-2.fc19.x86_64

How reproducible:
Always

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

Actual results:


Expected results:


Additional info:
This is exactly the same bug:
https://bugs.launchpad.net/ubuntu/+source/vino/+bug/369181

Comment 1 Steve 2013-07-07 14:14:43 UTC
Created attachment 769993 [details]
dconf Editor

Comment 2 Erik P. Olsen 2013-07-19 19:58:56 UTC
This problem also exists when connecting using tigervnc on both systems. On my system with xfce and no gnome the circumvention cannot be used.

Comment 3 J. Adam Craig 2013-07-23 15:06:49 UTC
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:

* Encryption:
  - None
  - TLS with anonymous certificates
  - TSL with X509 certificates

* Authentication:
  - None
  - 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

Comment 4 Nik Zbugz 2013-08-18 11:42:53 UTC
I confirm that vino-3.8.1.2.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).

Comment 5 Bill McGonigle 2013-11-10 16:10:32 UTC
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.

Comment 6 Steve 2013-12-17 09:32:00 UTC
This bug is not fixed in F20. Changing version to 20.

Comment 7 Stewart Adam 2014-01-01 02:57:07 UTC
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).

Comment 8 Ashish Shavarna 2014-02-12 23:02:16 UTC
Thanks, the solution worked for me with dconf-editor settings.

Comment 9 Felipe Diefenbach 2014-03-03 19:44:37 UTC
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.

Comment 10 Masaki Furuta 2014-03-10 11:47:26 UTC
I've checked this can set require-encryption value to false.

gsettings set org.gnome.Vino require-encryption false

Comment 11 romano 2014-04-15 14:34:15 UTC
Reported upstream at https://bugzilla.gnome.org/show_bug.cgi?id=728267

Comment 12 Romano Giannetti 2014-04-18 15:59:21 UTC
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.

Comment 15 David King 2015-01-12 14:50:50 UTC

*** This bug has been marked as a duplicate of bug 987981 ***


Note You need to log in before you can comment on or make changes to this bug.