Bug 981984 - Can't connect to Vino, except with Vinagre
Can't connect to Vino, except with Vinagre
Status: CLOSED DUPLICATE of bug 987981
Product: Fedora
Classification: Fedora
Component: vino (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: David King
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-07 10:13 EDT by Steve
Modified: 2016-08-10 14:31 EDT (History)
25 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-01-12 09:50:50 EST
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 10:13 EDT, Steve
no flags Details
dconf Editor (3.86 MB, image/png)
2013-07-07 10:14 EDT, Steve
no flags Details

  None (edit)
Description Steve 2013-07-07 10:13:03 EDT
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 10:14:43 EDT
Created attachment 769993 [details]
dconf Editor
Comment 2 Erik P. Olsen 2013-07-19 15:58:56 EDT
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 11:06:49 EDT
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 07:42:53 EDT
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 11:10:32 EST
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 04:32:00 EST
This bug is not fixed in F20. Changing version to 20.
Comment 7 Stewart Adam 2013-12-31 21:57:07 EST
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 18:02:16 EST
Thanks, the solution worked for me with dconf-editor settings.
Comment 9 Felipe Diefenbach 2014-03-03 14:44:37 EST
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 07:47:26 EDT
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 10:34:15 EDT
Reported upstream at https://bugzilla.gnome.org/show_bug.cgi?id=728267
Comment 12 Romano Giannetti 2014-04-18 11:59:21 EDT
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 09:50:50 EST

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