Bug 1062660
Summary: | virt-manager non-root qemu+ssh remote connect fails: no authentication agent available | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Scott Poore <spoore> |
Component: | virt-manager | Assignee: | virt-mgr-maint |
Status: | CLOSED WONTFIX | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.6 | CC: | acathrow, berrange, crobinso, gscrivan |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-02-07 17:26:22 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Scott Poore
2014-02-07 16:09:57 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. (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 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. 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 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 (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/ (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 |