-> When connecting via UltraVNC you get:

"No security type suitable for RFB 3.3 SUPPORTED" (typed suitable twice by mistake on original description)

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

Message using VNC Viewer for Google Chrome v1.0.5.229:

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

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?

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.

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)

(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?

(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!

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

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.

Created attachment 800931 [details]
patch to vino.spec

see previous comment

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

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

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

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

I really do not think that disabling encryption is a solution. All (ALL) what you type is going around the wire (or wifi) unencrypted.

(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

    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

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.

(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

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.

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.

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.

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

*** Bug 981984 has been marked as a duplicate of this bug. ***

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.

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

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/

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

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.