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 1343361 - SASL GSSAPI authentication is broken on spice-gtk
Summary: SASL GSSAPI authentication is broken on spice-gtk
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: spice-gtk
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Pavel Grunt
QA Contact: SPICE QE bug list
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-07 08:25 UTC by Fabiano Fidêncio
Modified: 2016-11-04 01:21 UTC (History)
6 users (show)

Fixed In Version: spice-gtk-0.31-4.el7
Doc Type: Bug Fix
Doc Text:
Cause: spice-gtk is not trying to authenticate when an username is missing Consequence: it is not possible to authenticate if the username is not required Fix: Allow to authenticate when the username is not specified Result: SASL GSSAPI authentication works
Clone Of:
Environment:
Last Closed: 2016-11-04 01:21:12 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
spice-gtk SASL2 log (2.09 KB, text/plain)
2016-09-27 11:24 UTC, David Jaša 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2229 0 normal SHIPPED_LIVE virt-viewer, libgovirt, spice-gtk, and usbredir bug fix and enhancement update 2016-11-03 13:26:58 UTC

Description Fabiano Fidêncio 2016-06-07 08:25:00 UTC 
SASL GSSAPI doesn't work, leaving the user with a request to enter "server password" instead of logging in the server machine.

See: https://vda.li/en/posts/2016/05/30/Single-sign-on-to-virtual-machines/ for more details.

And here is the proposed patch: https://lists.freedesktop.org/archives/spice-devel/2016-June/029883.html
Comment 2 Pavel Grunt 2016-06-17 08:38:16 UTC 
Fixed upstream:
https://cgit.freedesktop.org/spice/spice-gtk/commit/?id=fb8e51667b9fa63497e413fb4fd484d23b772788
Comment 5 David Jaša 2016-09-23 23:22:53 UTC 
The current build keeps asking password even though it contains the patch and the program goes through the lines added. So the patch is in but the bug is not fixed yet.
Comment 7 David Jaša 2016-09-24 00:00:34 UTC 
When accessing VNC server of the same VM, I'm getting esesntially the same disconnection:
(remote-viewer:31390): GSpice-DEBUG: spice-channel.c:1584 main-1:0: Client start negotiation mechlist 'GSS-SPNEGO,GSSAPI,DIGEST-MD5'
(remote-viewer:31390): GSpice-DEBUG: spice-channel.c:1413 main-1:0: Filled SASL interact
(remote-viewer:31390): GSpice-DEBUG: spice-channel.c:1584 main-1:0: Client start negotiation mechlist 'GSS-SPNEGO,GSSAPI,DIGEST-MD5'
(remote-viewer:31390): GSpice-DEBUG: spice-channel.c:1607 main-1:0: Server start negotiation with mech GSS-SPNEGO. Data 1243 bytes 0xad1920 '`\x82\u0004\xd7\u0006\u0006+\u0006\u0001\u0005\u0005\u0002\xa0\x82\u0004\xcb0\x82\u0004Ǡ\u000d0\u000b\u0006	*\x86H\x86\xf7\u0012\u0001\u0002\u0002\xa2\x82\u0004\xb4\u0004\x82\u0004\xb0`\x82\u0004\xac\u0006	*\x86H\x86\xf7\u0012\u0001\u0002\u0002\u0001'
(remote-viewer:31390): GSpice-DEBUG: spice-channel.c:1633 main-1:0: Getting sever start negotiation reply
(remote-viewer:31390): GSpice-DEBUG: spice-channel.c:995 main-1:0: Closing the connection: spice_channel_read() - ret=0
(remote-viewer:31390): GSpice-DEBUG: spice-channel.c:2569 main-1:0: Coroutine exit main-1:0
(remote-viewer:31390): GSpice-DEBUG: spice-channel.c:2776 main-1:0: reset 
(remote-viewer:31390): GSpice-DEBUG: channel-main.c:1582 agent connected: no
(remote-viewer:31390): GSpice-DEBUG: spice-channel.c:2704 main-1:0: channel reset

Can somebody see if it is configuration issue on my side or that the bug is not fixed yet?
Comment 8 David Jaša 2016-09-27 08:01:57 UTC 
Wrong paste in previous comment, corect paste for VNC is:
(remote-viewer:16272): gtk-vnc-DEBUG: vncconnection.c Client start negotiation mechlist 'GSS-SPNEGO,GSSAPI,DIGEST-MD5'
(remote-viewer:16272): gtk-vnc-DEBUG: vncconnection.c Server start negotiation with mech GSS-SPNEGO. Data 693 bytes 0xb618f0 '`\x82\u0002\xb1\u0006\u0006+\u0006\u0001\u0005\u0005\u0002\xa0\x82\u0002\xa50\x82\u0002\xa1\xa0\u000d0\u000b\u0006	*\x86H\x86\xf7\u0012\u0001\u0002\u0002\xa2\x82\u0002\x8e\u0004\x82\u0002\x8a`\x82\u0002\x86\u0006	*\x86H\x86\xf7\u0012\u0001\u0002\u0002\u0001'
(remote-viewer:16272): gtk-vnc-DEBUG: vncconnection.c Getting sever start negotiation reply
(remote-viewer:16272): gtk-vnc-DEBUG: vncconnection.c Read error Resource temporarily unavailable
Comment 10 David Jaša 2016-09-27 11:24:01 UTC 
Created attachment 1205171 [details]
spice-gtk SASL2 log

So the problem was in in my configuration. Contrary to info in [1], the sasl2 configuration file for qemu + vnc/spice on RHEL 7 is /etc/sasl2/qemu.conf. Once there, both VNC and Spice work correctly with sasl/gssapi (see attachment for successfull SASL authentication log)
Comment 12 Alexander Bokovoy 2016-09-29 07:44:43 UTC 
(In reply to David Jaša from comment #10)
> Created attachment 1205171 [details]
> spice-gtk SASL2 log
> 
> So the problem was in in my configuration. Contrary to info in [1], the
> sasl2 configuration file for qemu + vnc/spice on RHEL 7 is
> /etc/sasl2/qemu.conf. Once there, both VNC and Spice work correctly with
> sasl/gssapi (see attachment for successfull SASL authentication log)

The article you reference was tested with Fedora: "It is matter of setting appropriate configuration variables in /etc/libvirt/libvirtd.conf and /etc/libvirt/qemu.conf, and tuning /etc/sasl2/libvirt.conf and /etc/sasl2/qemu.conf to allow SASL GSSAPI authentication."

The article also references a third-party provided HOWTO on freeipa.org, http://www.freeipa.org/page/Libvirt_with_VNC_Consoles. The howto talks about /etc/sasl2/qemu-kvm.conf and /etc/sasl2/spice.conf. I believe these were the files in RHEL7.0 which later were moved to the current location. FreeIPA team does not curate HOWTOs provided by third parties.
Comment 14 errata-xmlrpc 2016-11-04 01:21:12 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-2229.html
Note You need to log in before you can comment on or make changes to this bug.