RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1341969 - vncviewer only supports VncAuth
Summary: vncviewer only supports VncAuth
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: tigervnc
Version: 7.3
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Jan Grulich
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 1280440
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-02 07:41 UTC by Jan Grulich
Modified: 2016-11-04 01:30 UTC (History)
9 users (show)

Fixed In Version: tigervnc-1.3.1-8.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1280440
Environment:
Last Closed: 2016-11-04 01:30:19 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2237 0 normal SHIPPED_LIVE tigervnc bug fix and enhancement update 2016-11-03 13:28:30 UTC

Description Jan Grulich 2016-06-02 07:41:49 UTC
+++ This bug was initially created as a clone of Bug #1280440 +++

Description of problem:

The vncviewer with Fedora 23 seems to only support VncAuth for SecurityType. I have a 1.5.0 tigervnc server running which usually uses TLSPlain and PAM for Authentication and the vncviewer in Fedora 23 doesn't work with it. 

The Binary's from tigervnc.org (OSX and Windows), and the RPMs there for EL5 and 6 work just fine. 

I cycled through all of the available security types on the server one by one i.e. run 1: -SecurityTypes=TLSPlain, run2: -SecurityTypes=TLSVnc, run 3: -SecurityTypes=VncAuth, etc. With the Fedora version This fails with the error: "No matching security types" until I get to VncAuth, which then succeeds.

When I enable all SecurityTypes on the tigervnc server, the Fedora vncviewer ends up negotiating VncAuth (no surprise) where the binaries from tigervnc.org end up selecting TLSPlain (which is what I'd want).

For now I'm using Remmina as my viewer (which works) but I the performance of the tigervnc vncviewer is so much better and more configurable than Remmina...

Version-Release number of selected component (if applicable):

tigervnc-1.5.0-3.fc23.x86_64

How reproducible:

Everytime I launch vncviewer to a server that doesn't have VncAuth as a SecurityType

Steps to Reproduce:
1. Have a TigerVNC Server with a config that doesn't allow VncAuth like "-SecurityTypes=TLSPlain -PlainUsers=me -PAMService=login"

2. Launch vncviewer i.e vncviewer my.machine:1 or vncviewer

Actual results:
See error: No matching security types

Expected results:
A prompt to enter username and credentials

Additional info:

Looking at tigervnc's own rpm and docs, it seems like the Fedora vncviewer could have been compiled without gnutls support.

--- Additional comment from Jan Grulich on 2015-11-12 03:26:16 EST ---

Might be related to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=692048

Can you try the scratch build below which has the fix above disabled? 
Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=11800861

--- Additional comment from Joel Burleson-Davis on 2015-11-12 10:08:37 EST ---

The scratch build worked just fine.

--- Additional comment from Joel Burleson-Davis on 2015-11-30 10:28:21 EST ---

This issue came back with tigervnc-1.5.0-4.fc23.x86_64

--- Additional comment from Jan Grulich on 2015-12-03 05:47:48 EST ---

That's because I didn't change or remove that patch yet, I'll get to it when I have some time, the new build was just rebuild against latest xorg-11-server.

--- Additional comment from Fedora Update System on 2016-05-23 12:54:50 EDT ---

tigervnc-1.6.0-4.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-a4d8082776

--- Additional comment from Fedora Update System on 2016-05-23 22:55:03 EDT ---

tigervnc-1.6.0-4.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-a4d8082776

--- Additional comment from Fedora Update System on 2016-05-24 14:02:02 EDT ---

tigervnc-1.6.0-4.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

--- Additional comment from Brian Lane on 2016-05-31 17:56:03 EDT ---

Dropping that patch has broken tigervnc in F24, at least.

The installation images use it like this (I added the -Log for debugging):


21:52:13,346 INFO program: Running... Xvnc :1 -depth 16 -br -Log *:stderr:100 IdleTimeout=0 -auth /dev/null -once DisconnectClients=false desktop=Fedora 24 installation on host 192.168.101.102 SecurityTypes=None rfbauth=0
21:52:16,254 INFO program: Running... //usr/bin/vncconfig -nowin -display :1
21:52:16,301 INFO program: Running... metacity --display :1 --sm-disable

When I try to connect with vinagre it logs this:

Tue May 31 21:52:25 2016
 Connections: accepted: 192.168.101.5::43650
 XserverDesktop: new client, sock 13
 SConnection: reading protocol version
 SConnection: Client needs protocol version 3.8
 SConnection: processing security type message
 SConnection: Client requests security type VeNCrypt(19)
 SConnection: processing security message
 SConnection: processing security message
 SConnection: processing security message
 XserverDesktop: client gone, sock 13
 Connections: closed: 192.168.101.5::43650 (Clean disconnection)
 EncodeManager: Framebuffer updates: 0
 EncodeManager:   Total: 0 rects, 0 pixels
 EncodeManager:          0 B (1:-nan ratio)

Nightly builds with 1.6.0-4 are failing. A Previous nightly, with 1.6.0-3, works fine.

It looks like the patch you dropped also dropped accepting VeNCrypt.

--- Additional comment from Fedora Blocker Bugs Application on 2016-05-31 17:58:45 EDT ---

Proposed as a Blocker for 25-alpha by Fedora user bcl using the blocker tracking app because:

 Updated tigervnc-1.6.0-4 breaks inst.vnc on the installer boot.iso

--- Additional comment from Brian Lane on 2016-05-31 18:00:15 EDT ---

Just to clarify, I am talking about the netinst boot.iso where you pass inst.vnc to start Xvnc in the installer environment. You cannot connect with any of the regularly available clients, like vinagre.

--- Additional comment from Brian Lane on 2016-05-31 18:01:21 EDT ---



--- Additional comment from Brian Lane on 2016-05-31 19:19:27 EDT ---

Sorry about that, I meant to make this a F24 Final Blocker not F25 Alpha.

--- Additional comment from Adam Williamson on 2016-05-31 19:32:13 EDT ---

+1 blocker, clearly violates "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces." - https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria#Installation_interfaces

--- Additional comment from Fedora Update System on 2016-06-01 04:11:25 EDT ---

tigervnc-1.6.0-5.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-5714267e09

--- Additional comment from Jan Grulich on 2016-06-01 04:13:09 EDT ---

I pushed a new build to Fedora 24/25 enabling the previous patch again for now. I'll try to find a way to make this work on both sides.

--- Additional comment from Jan Grulich on 2016-06-01 08:07:45 EDT ---

Could you please also test the build below? I would like to know whether it fixes the original issue and doesn't break other clients like vinagre.

Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=14337240

--- Additional comment from Joel Burleson-Davis on 2016-06-01 10:04:16 EDT ---

The scratch build works for me when using PAM.

--- Additional comment from Jan Grulich on 2016-06-01 10:57:39 EDT ---

Ok, now I need a confirmation that it works even with vinagre.

--- Additional comment from Brian Lane on 2016-06-01 13:22:16 EDT ---

(In reply to Jan Grulich from comment #18)
> Ok, now I need a confirmation that it works even with vinagre.

Works great, thanks. I built a f24 boot.iso with the update and it works fine.

--- Additional comment from Jan Grulich on 2016-06-01 14:23:22 EDT ---

I wanted to know whether it works with the scratch build from comment 16, the package from update is the same as it was before and thus doesn't work when using PAM.

--- Additional comment from Brian Lane on 2016-06-01 15:15:15 EDT ---

By 'update' I meant the scratch build, 1.6.0-6 works fine :)

Comment 1 Jan Grulich 2016-06-02 08:07:26 UTC
Fixed in tigervnc-1.3.1-8.el7.

Comment 5 errata-xmlrpc 2016-11-04 01:30:19 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2237.html


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