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 1062660 - virt-manager non-root qemu+ssh remote connect fails: no authentication agent available
Summary: virt-manager non-root qemu+ssh remote connect fails: no authentication agent ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-manager
Version: 6.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: virt-mgr-maint
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-07 16:09 UTC by Scott Poore
Modified: 2019-05-20 11:08 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-07 17:26:22 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Scott Poore 2014-02-07 16:09:57 UTC
Description of problem:

I'm trying to run virt-manager on my laptop and connect to libvirtd on my desktop to access guests there.  And, I'm trying to do this as non-root.

This is what I'm seeing:

ON LAPTOP:

virt-manager
File -> Add Connection
  Hypervisor:  QEMU/KVM
  Connect to remote host (x)
  Method:  SSH
  Username: spoore
  Hostname:  spoore-desktop
Connect

This is failing with an error like this (full details below):

Authorization requires authentication but no agent is available.

So, what am I missing to run virt-manager on my laptop and connect to my desktop as a non-root user?

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

Laptop:
- RHEL6 running gnome.
- virt-manager-0.9.0-18.el6.x86_64

Desktop
- Fedora 19.
- libvirt-daemon-1.0.5.9-1.fc19.x86_64

How reproducible:
Always

Steps to Reproduce:
1.  libvirtd setup on system1
2.  virt-manager installed on system2
3.  on system2 run virt-manager and try to connect to system1 as a non-root user

Actual results:

{{{

Unable to open a connection to the libvirt management daemon.

Libvirt URI is: qemu+ssh://spoore@spoore-desktop/system

Verify that:
 - The 'libvirtd' daemon has been started


authentication failed: polkit: polkit\56retains_authorization_after_challenge=1
Authorization requires authentication but no agent is available.


Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 1154, in _open_thread
    self.vmm = self._try_open()
  File "/usr/share/virt-manager/virtManager/connection.py", line 1138, in _try_open
    flags)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 102, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: authentication failed: polkit: polkit\56retains_authorization_after_challenge=1
Authorization requires authentication but no agent is available.

}}}

Expected results:

I expected it to prompt for the user password and connect like it does for root or like it does when virt-manager is run locally on the desktop.

Additional info:

Now, I can do the same but use root user and it works.  It prompts me for the root password and then connects as expected.

I've also tried setting polkit rules like this on the DESKTOP:

# cat /etc/polkit-1/rules.d/80-libvirt-manage.rules
polkit.addRule(function(action, subject) {
  if (action.id == "org.libvirt.unix.manage" && subject.local && subject.active && subject.isInGroup("wheel")) {
      return polkit.Result.YES;
  }
});

No luck.  Now, I can run virt-manager fine from the DESKTOP.  And, I can also run it via ssh -Y spoore-desktop if I first run /usr/libexec/polkit-gnome-authentication-agent-1.

Comment 1 Cole Robinson 2014-02-07 16:27:00 UTC
So the machine running virt-manager is RHEL6? You need to file this bug against RHEL6. Reassigning

Please also confirm if virsh --connect qemu+ssh://spoore@spoore-desktop/system   as regular user from RHEL6 -> F19 is erroring in the same way. If so then there's something wrong at the libvirt level AFAICT, it shouldn't be touching polkit in that path.

Comment 3 Scott Poore 2014-02-07 16:54:55 UTC
(In reply to Cole Robinson from comment #1)
> So the machine running virt-manager is RHEL6? You need to file this bug
> against RHEL6. Reassigning

Sorry, didn't know if I should file it against RHEL6 or Fedora19 so went with Virtualization tools.  Thanks for switching that for me.

> 
> Please also confirm if virsh --connect
> qemu+ssh://spoore@spoore-desktop/system   as regular user from RHEL6 -> F19
> is erroring in the same way. If so then there's something wrong at the
> libvirt level AFAICT, it shouldn't be touching polkit in that path.

Yes, it is shows the same error for virsh as well:

[spoore@spoore ~]$ virsh --connect qemu+ssh://spoore@spoore-desktop/system
error: authentication failed: polkit: polkit\56retains_authorization_after_challenge=1
Authorization requires authentication but no agent is available.

error: failed to connect to the hypervisor

Are there any logs I can look for other than journalctl?

This is from the virsh test just now:

Feb 07 10:46:48 spoore-desktop sshd[33638]: Accepted publickey for spoore from 192.168.0.190 port 36186 ssh2
Feb 07 10:46:48 spoore-desktop sshd[33638]: pam_unix(sshd:session): session opened for user spoore by (uid=0)
Feb 07 10:46:48 spoore-desktop systemd-logind[625]: New session 63 of user spoore.
Feb 07 10:46:49 spoore-desktop libvirtd[33086]: Policy kit denied action org.libvirt.unix.manage from pid 33660, uid 1000: exit status 2
Feb 07 10:46:49 spoore-desktop libvirtd[33086]: authentication failed: polkit: polkit\56retains_authorization_after_challenge=1
Authorization requires authentication but no agent is available.

Feb 07 10:46:49 spoore-desktop sshd[33641]: Received disconnect from 192.168.0.190: 11: disconnected by user
Feb 07 10:46:49 spoore-desktop sshd[33638]: pam_unix(sshd:session): session closed for user spoore
Feb 07 10:46:49 spoore-desktop libvirtd[33086]: End of file while reading data: Input/output error
Feb 07 10:46:49 spoore-desktop systemd-logind[625]: Removed session 63.

Can I change logging for libvirtd to get more info maybe?

Thanks,
Scott

Comment 4 Scott Poore 2014-02-07 17:13:28 UTC
FYI, I just tested from another Fedora 19 machine except running LXDE and I see the same thing there.  I do see lxpolkit agent running there too in case that matters.

$ rpm -q virt-manager
virt-manager-0.10.0-4.fc19.noarch

And quick check with virsh as well:
$ virsh --connect qemu+ssh://spoore@spoore-desktop/system
spoore@spoore-desktop's password: 
error: failed to connect to the hypervisor
error: authentication failed: polkit: polkit\56retains_authorization_after_challenge=1
Authorization requires authentication but no agent is available.

Also, with this test I did realize something about the other test.  On this Fedora 19 machine, I do not have ssh keys setup to the desktop.  On the other I did.  

So, on the original laptop, I'm not getting prompted for a password because I've got keys setup.  On this F19 laptop, I am being prompted for a password and then it shows the error.

Not sure if that helps or complicates things.

Comment 5 Cole Robinson 2014-02-07 17:26:22 UTC
Ah, actually looking closer now, I realize the issue. You need to use the 'root' user in the URI. Since you are using the regular user spoore, libvirtd on the remote host wants to try to auth with polkit. There isn't any polkit agent running where libvirtd is, since it doesn't have a desktop session. Granted, even if there _was_ an agent running, it could only pop open a password dialog on the remote host's desktop, it wouldn't work over the remote connection.

So the solution is use qemu+ssh://root@$HOST/system. If you want to use a regular user for a remote connection, you need to set up something like sasl: http://libvirt.org/auth.html#ACL_server_username

Comment 6 Scott Poore 2014-02-07 19:43:31 UTC
Is this something that we can get as an RFE?

Seems like it would be a pretty useful option to me.

I thought requiring actual root user access like that was contrary to most common security practices today, no?

And I can see users wanting to rely upon the normal system authorization and authentication mechanisms if possible and not building another to maintain like the SASL solution.  I can certainly try that but, that would then require parallel maintenance of users and passwords.

The Kerberos solution might be nice in some environments but, what about the case where users don't have access to the kdc server?

This just seems like expected behavior to me but, granted this is the first time I've tried to run this as non root.

Do you know if the root of this problem is because polkit can't talk back to the originating host to see the agent it is running?

Is this maybe a policy kit issue?

Thanks,
Scott

Comment 7 Cole Robinson 2014-02-07 19:54:31 UTC
(In reply to Scott Poore from comment #6)
> Is this something that we can get as an RFE?
> 
> Seems like it would be a pretty useful option to me.
> 
> I thought requiring actual root user access like that was contrary to most
> common security practices today, no?
> 

When you use virt-manager/polkit on the local machine, you have to enter root password as well. Having access to qemu:///system basically allows anyone to compromise the machine as it is, so whether that's done through an explicit root password over SSH or through root password via polkit dialog doesn't change the risk IMO.

> 
> Do you know if the root of this problem is because polkit can't talk back to
> the originating host to see the agent it is running?
> 
> Is this maybe a policy kit issue?
> 

It's a deliberate design decision of polkit to not have any agent available for non-desktop sessions, like SSH. You can try taking it up with them but I'd bet all my money that this use case won't change their minds.

There's other options too: you can tweak polkit on the remote machine to not require a password for spoore to access libvirt:  http://goldmann.pl/blog/2012/12/03/configuring-polkit-in-fedora-18-to-access-virt-manager/

Comment 8 Scott Poore 2014-02-07 20:31:29 UTC
(In reply to Cole Robinson from comment #7)
...
> When you use virt-manager/polkit on the local machine, you have to enter
> root password as well. Having access to qemu:///system basically allows
> anyone to compromise the machine as it is, so whether that's done through an
> explicit root password over SSH or through root password via polkit dialog
> doesn't change the risk IMO.

But, I'm not entering the root password on my local desktop when I run virt-manager.  I thought the access had all been resolved to group access checks?  My non-root user account is in the wheel group.  I had thought that was just a new default around F18 timeframe....no?

...
> There's other options too: you can tweak polkit on the remote machine to not
> require a password for spoore to access libvirt: 
> http://goldmann.pl/blog/2012/12/03/configuring-polkit-in-fedora-18-to-access-
> virt-manager/

I'd already tried that polkit example (from comment #0 additional info).  That didn't seem to help as I still saw the same errors.  Not sure if it's required but, I also restart polkit in case it needed that to re-read new policy rule files.

FYI, I found something that worked.

I changed libvirtd.conf and set the following options (mostly just uncommenting in the config file):

unix_sock_group = "libvirt"
unix_sock_rw_perms = "0770"
unix_sock_dir = "/var/run/libvirt"
auth_unix_ro = "none"
auth_unix_rw = "none"

I had already created a libvirt group and added my user account to that.  That seemed to solve my problem:

[spoore@spoore ~]$ virsh -c qemu+ssh://spoore@spoore-desktop/system
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh # quit

I tested with a user not in libvirt to confirm that access wasn't wide open but, locked down to socket file access via the group.  Seemed to work too:

[spoore@spoore ~]$ virsh -c qemu+ssh://testuser@spoore-desktop/system
testuser@spoore-desktop's password: 
error: End of file while reading data: Ncat: Permission denied.: Input/output error
error: failed to connect to the hypervisor

Thanks,
Scott


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