Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Vino authentication issue / not matching security types / No security type suitable for RFB 3.3 Supported / Authentication mechanism requested cannot be provided by the computer|
|Product:||[Fedora] Fedora||Reporter:||Carlos Cestero <tekunix>|
|Component:||vino||Assignee:||David King <amigadave>|
|Status:||CLOSED NOTABUG||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||19||CC:||amigadave, amlau, berrange, bohne.andrew, bugzilla, dajomas, danieltdev, danny, debarshir, enimac, erik-fedora, farrellj, gabriel, haxthausen, jay, jeff.raber, josh.zeno, jpoimboe, kem, lane, lavie, mario.mikocevic, michael, noelgrandin, pilon24, promiseland.tony, romano.giannetti, sandmann, teppot, yoursdearboy, yselkowi|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-01-12 09:44:35 EST||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Carlos Cestero 2013-07-24 09:47:27 EDT
Description of problem: Vino authentication issue / not matching security types / No security type suitable for RFB 3.3 Suitable / Authentication mechanism requested cannot be provided by the computer... etc... Version-Release number of selected component (if applicable): Name : vino Version : 3.8.1 Release : 2.fc19 Architecture: x86_64 Install Date: Tue 23 Jul 2013 05:15:27 PM EDT Group : User Interface/Desktops Size : 2179665 License : GPLv2+ Signature : RSA/SHA256, Tue 11 Jun 2013 10:00:13 AM EDT, Key ID 07477e65fb4b18e6 Source RPM : vino-3.8.1-2.fc19.src.rpm Build Date : Mon 10 Jun 2013 10:17:08 PM EDT Build Host : buildvm-24.phx2.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project URL : http://www.gnome.org Summary : A remote desktop system for GNOME Description : Vino is a VNC server for GNOME. It allows remote users to connect to a running GNOME session using VNC. How reproducible: Always... in my case... Upgraded 3 laptops 2 Acer's & 1 Asus from Fedora 18 to 19 via fedup... and all 3 computers give same error... Steps to Reproduce: 1. Enable Desktop Sharing 2. Try to connect to F19 computer... 3. You will see vino authentication issue. Actual results: Remote Desktop not working / Broken Expected results: Successful Remote Desktop connection. Additional info: -> When connecting via UltraVNC you get: "No security type suitable for RFB 3.3 Suitable" -> When connecting via Android App VNC Viewer 1.2.6 you get: "Authentication mechanism requested cannot be provided by the computer"
Comment 1 Carlos Cestero 2013-07-24 10:08:55 EDT
-> When connecting via UltraVNC you get: "No security type suitable for RFB 3.3 SUPPORTED" (typed suitable twice by mistake on original description)
Comment 2 Shamyr 2013-07-24 19:18:48 EDT
Message using VNC Viewer (RealVNC) in MacOSX 10.8.4: "Unable to connect to VNC Server using your chosen security setting. Either upgrade VNC Server to a more recent version from RealVNC, or select a weaker level of encryption." Vino's Connection worked for Fedora 16,17 & 18
Comment 3 Josh Zeno 2013-07-24 20:18:35 EDT
Message using VNC Viewer for Google Chrome v126.96.36.199: Error: "The authentication mechanism requested cannot be provided by the computer." Used FedUp yesterday to upgrade from F18 to F19. Also, Vino's connection worked for Fedora 16,17 & 18
Comment 4 Carlos Cestero 2013-07-24 20:31:53 EDT
Currently the only way to have remote desktop on F19 is using this method: https://bugzilla.redhat.com/show_bug.cgi?id=896648 (Comment 24 from me) HOW TO MAKE TIGERVNC WORK WITH FEDORA 19 (GNOME)- STEP BY STEP GUIDE 1. yum -y install tigervnc-server 2. su fedora (your username, not fedora) 3. vncpasswd 4. vncserver :1 5. vncserver -kill :1 6. nano /home/fedora/.vnc/xstartup (remember, fedora is an example) #twm & exec gnome-session & 7. (From comment #15) Add "-session optional pam_systemd.so" line to /etc/pam.d/runuser-l so runuser-l will look like this: auth include runuser session optional pam_keyinit.so force revoke -session optional pam_systemd.so session include runuser 8. Edit vncserver@.service under /lib/systemd/system nano /lib/systemd/system/vncserver@.service and insert a valid user to replace <USER> ExecStart=/sbin/runuser -l <USER> -c “/usr/bin/vncserver %i” change to ExecStart=/sbin/runuser -l fedora -c “/usr/bin/vncserver %i” where fedora is the user you want to run the session as. 9. Also change Type=simple and add -fg to vncserver@.service... Should look like this: (Copy & Paste it, remember to replace fedora with your username) [Service] Type=simple # Clean any existing files in /tmp/.X11-unix environment ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :' ExecStart=/sbin/runuser -l fedora -c "/usr/bin/vncserver -fg %i" ExecStop=/sbin/runuser -l fedora -c "/usr/bin/vncserver -kill %i" 10. Reload the configuration change: systemctl daemon-reload 11. (Optional STEP)Edit line: nano /usr/bin/vncserver (and look for the following line and replace geometry with your choice) $geometry = "1366x768"; 12. Enable the vnc service: systemctl enable vncserver@:1.service 13. DONE! WORKING TIGERVNC SERVER WITH F19! Now... can anyone provide a step by step on how to make tigervnc work with cinnamon instead of Gnome?
Comment 5 Samuel Irlapati 2013-07-25 17:39:41 EDT
I have used x11vnc to get vnc working again from remote machines. the command i use is "x11vnc -usepw -forever -display :0" Type this command in a terminal and leave it running. Alternatively you could try adding to gnome-sessions-properties as a command to start when the desktop starts. Once the above command is running all other previous methods connecting with vncviewers should work including tunneling. I used x11vnc because in days old before there was vino, there was x11vnc. It is similar to vino in that it starts a vncserver on display 0.
Comment 6 Johan G. 2013-08-21 05:01:23 EDT
I have compiled Vino 3.9.3 as is and it causes the same issue. It advertises security type 18 which is TLS and as far as I know only Remmina supports this security type. On Windows, I have tried TightVNC and RealVNC and both of them do not support TLS Then I compiled Vino 3.9.3 without gnutls (./configure --without-gnutls) It advertises security type 2 which is VNC Authentication Now I can connect to Fedora 19 desktop running Cinnamon (although view-only since my XServer does not support the XTest extension but that is another issue I need to tackle)
Comment 7 Teppo Turtiainen 2013-08-21 11:06:27 EDT
(In reply to Johan G. from comment #6) > Then I compiled Vino 3.9.3 without gnutls (./configure --without-gnutls) > > It advertises security type 2 which is VNC Authentication Is this the correct solution? Can we have an update with vino compiled with --without-gnutls?
Comment 8 Carlos Cestero 2013-08-21 21:45:53 EDT
(In reply to Johan G. from comment #6) > I have compiled Vino 3.9.3 as is and it causes the same issue. > > It advertises security type 18 which is TLS and as far as I know only > Remmina supports this security type. > > On Windows, I have tried TightVNC and RealVNC and both of them do not > support TLS > > Then I compiled Vino 3.9.3 without gnutls (./configure --without-gnutls) > > It advertises security type 2 which is VNC Authentication > > Now I can connect to Fedora 19 desktop running Cinnamon (although view-only > since my XServer does not support the XTest extension but that is another > issue I need to tackle) Can you be kind enough to provide us a solution? Maybe an rpm package or a how to guide? Thank you!
Comment 9 Mohamed Amine Bergach 2013-09-05 12:37:08 EDT
First of all, thank you Johan for your workaround, for me I will describe a full fix for this issue: 0) delete previous vino installations >yum erase vino 1) start by downloading the source of vino 3.9.3 >wget https://git.gnome.org/browse/vino/snapshot/vino-3.9.3.tar.gz 2) you have to be root >su - >root password 3) untar vino >tar -xf vino-3.9.3.tar.gz 4) >cd vino-3.9.3 5) install missing packages using yum see vino README file 6) very important to avoid the XTest error : install libXtst-devel >yum install libXtst-devel >ldconfig 7) >./autogen.sh 8) >./configure --without-gnutls 9) >make 10) >make install 11) run your server and enjoy :) Thanks, Mohamed
Comment 10 Chuck Lane 2013-09-21 12:08:26 EDT
I got the vino src rpm, and tried to rebuild. Funny thing, it seems some of the ./configure options were changed from --enable/disable to --with/without; and while the spec file had "--disable-gnutls", it had no effect, since configure was looking for "--without-gnutls". Also, if gnutls is omitted, you have to disable telepathy, because of nested includes creating undefined variables. Anyway, attaching a diff in specfiles; I changed the release to add a CEL to distinguish from the standard release, and fixed a date in the changelog that had rpmbuild barfing.
Comment 11 Chuck Lane 2013-09-21 12:10:46 EDT
Created attachment 800931 [details] patch to vino.spec see previous comment
Comment 12 Phil Pilon 2013-10-31 20:41:24 EDT
can you please explain exactly what you mean i downloaded the spec file but should i do with it i have it in the vino folder Thanks Phil
Comment 13 Chuck Lane 2013-11-03 11:46:29 EST
(In reply to Phil Pilon from comment #12) > can you please explain exactly what you mean i downloaded the spec file but > should i do with it i have it in the vino folder > > Thanks > > Phil The spec file goes in the SPEC folder, when you rebuild the vino rpm from the .src.rpm.
Comment 14 Dominique Brazziel 2014-04-18 10:55:59 EDT
This bug is still happening in Fedora 20 (Vino version 3.10.1). vncviewer -log *:stderr:100 fedora VNC Viewer Free Edition 4.1.1 for X - built Feb 4 2013 16:56:44 Copyright (C) 2002-2005 RealVNC Ltd. See http://www.realvnc.com for information on VNC. Fri Apr 18 10:33:20 2014 CConn: connected to host fedora port 5900 CConnection: reading protocol version CConnection: Server supports RFB protocol version 3.7 CConnection: Using RFB protocol version 3.7 CConnection: processing security types message CConnection: Server offers security type [unknown secType](18) CConnection: No matching security types main: No matching security types The fix is pretty well documented here (build vino without gnutls), what is the holdup in implementing the fix? Remote desktop is a standard component of the gnome desktop, and it is important enough not to have it unusable (especially when it worked before).
Comment 15 Teppo Turtiainen 2014-04-18 20:29:36 EDT
Upstream bug https://bugzilla.gnome.org/show_bug.cgi?id=728267 has a possible workaround: > A solution is disabling the encryption completely, by > > gsettings set org.gnome.Vino require-encryption false
Comment 16 Romano Giannetti 2014-04-25 11:22:33 EDT
I really do not think that disabling encryption is a solution. All (ALL) what you type is going around the wire (or wifi) unencrypted.
Comment 17 Tony 2014-06-07 20:41:09 EDT
(In reply to Carlos Cestero from comment #4) > Currently the only way to have remote desktop on F19 is using this method: > > https://bugzilla.redhat.com/show_bug.cgi?id=896648 (Comment 24 from me) > > HOW TO MAKE TIGERVNC WORK WITH FEDORA 19 (GNOME)- STEP BY STEP GUIDE > > 1. yum -y install tigervnc-server > > 2. su fedora (your username, not fedora) > > 3. vncpasswd > > 4. vncserver :1 > > 5. vncserver -kill :1 > > 6. nano /home/fedora/.vnc/xstartup (remember, fedora is an example) > > #twm & > exec gnome-session & > > 7. (From comment #15) Add "-session optional pam_systemd.so" line to > /etc/pam.d/runuser-l so runuser-l will look like this: > > auth include runuser > session optional pam_keyinit.so force revoke > -session optional pam_systemd.so > session include runuser > > 8. Edit vncserver@.service under /lib/systemd/system > > nano /lib/systemd/system/vncserver@.service and insert a valid user to > replace <USER> > > ExecStart=/sbin/runuser -l <USER> -c “/usr/bin/vncserver %i” change to > > ExecStart=/sbin/runuser -l fedora -c “/usr/bin/vncserver %i” where fedora > is the user you want to run the session as. > > 9. Also change Type=simple and add -fg to vncserver@.service... > > Should look like this: (Copy & Paste it, remember to replace fedora with > your username) > > [Service] > Type=simple > # Clean any existing files in /tmp/.X11-unix environment > ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :' > ExecStart=/sbin/runuser -l fedora -c "/usr/bin/vncserver -fg %i" > ExecStop=/sbin/runuser -l fedora -c "/usr/bin/vncserver -kill %i" > > 10. Reload the configuration change: > > systemctl daemon-reload > > 11. (Optional STEP)Edit line: > > nano /usr/bin/vncserver (and look for the following line and replace > geometry with your choice) > > $geometry = "1366x768"; > > 12. Enable the vnc service: > > systemctl enable vncserver@:1.service > > 13. DONE! WORKING TIGERVNC SERVER WITH F19! > > Now... can anyone provide a step by step on how to make tigervnc work with > cinnamon instead of Gnome? Hello, Thanks for the step by step instructions. I was able to follow them pretty easily. Alas, I am trying to make TigerVNC work on a Fedora 20 system, and with only emerging Linux troubleshooting skills I don't seem to understand why I cant make a connection from my Windows machine. The instructions above all worked without any apparent issues. When I try to connect from Windows to my Fedora machine at port 5903, you will see that it is a port that is listening from the log file I will append, TigerVNC says "Unable to connect to socket, Connection timed out (10060)" Here is a log file I found at Owner-PC:3.log, I am unsure where else to look for troubleshooting, and I don't see anything that looks fatal in this log. Xvnc TigerVNC 1.3.0 - built Mar 19 2014 17:10:53 Copyright (C) 1999-2011 TigerVNC Team and many others (see README.txt) See http://www.tigervnc.org for information on TigerVNC. Underlying X server release 11404000, The X.Org Foundation Initializing built-in extension VNC-EXTENSION Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension GLX Sat Jun 7 19:08:01 2014 vncext: VNC extension running! vncext: Listening for VNC connections on all interface(s), port 5903 vncext: created VNC server for screen 0 gnome-session-is-accelerated: No hardware 3D support. gnome-session-check-accelerated: Helper exited with code 256 gnome-session-is-accelerated: No hardware 3D support. gnome-session-check-accelerated: Helper exited with code 256 ** (process:1750): WARNING **: software acceleration check failed: Child process exited with code 1 Thankx for any coaching! my Linux skills are still developing so specifics would be a real help for me. Tony
Comment 18 Tony 2014-06-07 22:29:26 EDT
Al righty then ... I made some progress. It turns out my ports were blocked by the firewall. I was able to open the ports by searching from the desktop activities for "firewall" then selecting the "ports" tab and adding the desired ports in the "public" zone. This at least got me prompted for the vnc password. I pretty much just get a black window for now, but I'm going to tackle that particular issue at a different time. Tony
Comment 20 Jason Farrell 2014-08-11 11:27:22 EDT
Just chiming in that this bug is still active as of today. Until it's fixed, the workaround -- gsettings set org.gnome.Vino require-encryption false -- is working and acceptable in my case, as I only use VNC on a secure LAN.
Comment 21 Lavie 2014-08-16 12:23:00 EDT
(In reply to Tony from comment #18) > Al righty then ... I made some progress. It turns out my ports were > blocked by the firewall. I was able to open the ports by searching from the > desktop activities for "firewall" then selecting the "ports" tab and adding > the desired ports in the "public" zone. > This at least got me prompted for the vnc password. I pretty much just > get a black window for now, but I'm going to tackle that particular issue at > a different time. > > Tony Tony - did you ever get beyond the black screen? Lavie
Comment 22 Haxthausen 2014-12-22 00:03:41 EST
Hello, any update on this issue? Looks like it is still occurring on Fedora 21 with vino.x86_64, version 3.14.1-1.fc21. Also the "gsettings set org.gnome.Vino require-encryption false" workaround doesn't appear to work for me, any clues? Thanks, Hax.
Comment 23 Fedora End Of Life 2015-01-09 14:04:50 EST
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Comment 24 Haxthausen 2015-01-09 14:20:49 EST
Hello, Since this issue is still occurring on Fedora 21 with vino.x86_64 version 3.14.1-1.fc21, can we please change the version of this bug in order to keep it open for correction? Thanks, Hax.
Comment 25 David King 2015-01-12 09:44:35 EST
As the upstream Vino maintainer I can explain the code a little bit. There are two GSettings keys which are relevant: require-encryption and authentication-methods. If require-encryption is set to true (the default), and authentication-methods is set to ['none'] (also the default), any user can connect without entering a password and the VNC traffic is encrypted. If require-encryption is then changed to false, there is no change to the reported VNC authentication types. However, there is a change to the accepted security types, which now allows no authentication (a better term would be "unencrypted"). If authentication-methods is changed to ['vnc'] (or rather, 'vnc' is present in the key), and a valid password is set, the reported security types are not changed, but the authentication types will be set to VNC authentication (password-based). The end result is that if you want to connect with clients that do not support the TLS encryption scheme (the security type) that Vino uses, the require-encryption key should be set to false. If you want a password to be required, make sure that 'vnc' is present in the authentication-methods key (which controls the authentication types). Building Vino without GnuTLS support is not necessary, which I verified just now by setting the require-encryption key to false. It does not seem like any fix is required, as Vino follows the GSettings keys correctly (as far as I can tell).
Comment 26 David King 2015-01-12 09:50:50 EST
*** Bug 981984 has been marked as a duplicate of this bug. ***
Comment 27 Daniel Berrange 2015-02-11 12:43:55 EST
FYI as a point of note the custom TLS auth type that VINO implements *is* supported by the GTK-VNC client, which is used by vinagre, remote-viewer (part of virt-viewer/virt-manager project) and by GNOME Boxes.
Comment 28 Romano Giannetti 2015-02-11 13:58:19 EST
@Daniel you are right --- the problems are mainly when connecting from a non-linux machine, like Windows. Last time I tried no client had this auth type.
Comment 29 Daniel Berrange 2015-02-12 04:53:23 EST
FYI the virt-viewer project provides windows builds, which include a binary called 'remote-viewer' that uses GTK-VNC and/or SPICE-GTK to connect to arbitrary remote desktops. This remote-viewer ought to be able to connect to Vino servers from Windows, though I've not tested with Vino from Windows myself. The URI yo'd want is vnc://hostname:port eg vnc://some.host.com:5900 for the first VNC display http://virt-manager.org/download/
Comment 30 Romano Giannetti 2015-02-12 05:31:50 EST
@Daniel thanks --- but it's a very "no-standard" thing for the average Windows user. None of the mainstream VNC viewer for windows (TightVNC, Chrome, TigerVNC, whatever) are compatible. And then there is Mac. I still think that this should be fixed in the server --- I am now back to my office and I have a Linux only setup, so I do not need it. But still, if I need to connect from the random PC here on my Uni (for which I do not control the installed software) I cannot use TightVNC to connect to my Linux PC unless I am willing to have thousand of student sniffing my password :-) (or doing a tunnel with ssh, which is what I do). The other solution is to ditch vino and use x11vnc. It's slower but it works.
Comment 31 Danny Staple 2015-06-26 14:44:20 EDT
Virt-viewer is not a solution - it doesn't actually appear to work at all - "not a graphic server", or less useful - a display with a message that closes before you get a chance to read it, and nothing logged on a console when running it there. Perhaps when introducing fabulous new encryption mechanisms, assisting other mainstream viewers in compatibility (tight vnc, real vnc, maybe the mac's Chicken of The VNC) might make sense? My only working solution is to disable the security mechanism - which seems a little unsatisfactory. This feels a bit like "works for me, ship it" - and this was closed a bit prematurely.