Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
Unable to open a connection to the libvirt management daemon.
Libvirt URI is: qemu+ssh://root.net/system
Verify that:
- The 'libvirtd' daemon has been started
Unable to open connection to hypervisor URI 'qemu+ssh://root.net/system':
cannot recv data: No protocol specified
(ssh-askpass:22562): Gtk-WARNING **: cannot open display: :0.0
Permission denied, please try again.
No protocol specified
(ssh-askpass:22563): Gtk-WARNING **: cannot open display: :0.0
Permission denied, please try again.
No protocol specified
(ssh-askpass:22564): Gtk-WARNING **: cannot open display: :0.0
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
: Connection reset by peer
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/connection.py", line 992, in _try_open
None], flags)
File "/usr/lib64/python2.6/site-packages/libvirt.py", line 111, in openAuth
if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: cannot recv data: No protocol specified
(ssh-askpass:22562): Gtk-WARNING **: cannot open display: :0.0
Permission denied, please try again.
No protocol specified
(ssh-askpass:22563): Gtk-WARNING **: cannot open display: :0.0
Permission denied, please try again.
No protocol specified
(ssh-askpass:22564): Gtk-WARNING **: cannot open display: :0.0
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
: Connection reset by peer
Maybe you need to install ssh-askpass in order to authenticate.
[ben@snog tmp]$ rpm -q virt-manager
virt-manager-0.8.4-8.el6.noarch
The problem seems to be one of access or privileges.
Sifting through the log you can see:
22562 execve("/usr/libexec/openssh/ssh-askpass", ["/usr/libexec/openssh/ssh-askpass", "root.net's passw"..
.], [/* 23 vars */]) = 0
...
22562 connect(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, 20) = 0
...
22562 access("/var/run/gdm/auth-for-ben-JwgDaN/database", R_OK) = -1 EACCES (Permission denied)
So what is happening is we exec a process ssh-askpass it tries to connect to the X server but to be able to connect to the screen it needs to get the authority file which ends up being denied for some reason even though the process was run as root.
Version-Release number of selected component (if applicable):
virt-manager-0.8.6-3.el6.noarch
How reproducible:
$ sudo virt-manager
you can't connect to a remote machines via ssh. The problem seems to have something to do with connecting back to the xserver.
however if you do:
$ virt-manager
you can connect.
Actual results:
Connection denied.
Expected results:
Connection succeeds.
Additional info:
I can reproduce. I managed to get it working with a libvirt patch:
diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c
index d4c0bdd..ad1c02e 100644
--- a/src/rpc/virnetsocket.c
+++ b/src/rpc/virnetsocket.c
@@ -606,7 +606,8 @@ int virNetSocketNewConnectSSH(const char *nodename,
virCommandAddEnvPass(cmd, "SSH_AUTH_SOCK");
virCommandAddEnvPass(cmd, "SSH_ASKPASS");
virCommandAddEnvPass(cmd, "DISPLAY");
- virCommandClearCaps(cmd);
+ virCommandAddEnvPass(cmd, "XAUTHORITY");
+ //virCommandClearCaps(cmd);
if (service)
virCommandAddArgList(cmd, "-p", service, NULL);
Passing through XAUTHORITY seems okay, but I don't think dropping ClearCaps wholesale is a good idea. Reassigning to libvirt to see if anyone has more thoughts.
Cole, I'm not sure anybody on the libvirt team is going to have more insight into this than you do. Would you mind submitting that patch to libvir-list for discussion there?
Hi,
I can reproduce this bug with libvirt-0.9.3-2.el6.x86_64
steps:
1) use a no-root user
$cat test.py
#!/usr/bin/python
import os
import sys
import libvirt
def drop_tty():
if os.fork() != 0:
os._exit(0)
os.setsid()
host = sys.argv[1]
# Need to drop controlling tty otherwise SSH won't call askpass
drop_tty()
libvirt.open("qemu+ssh://root@%s/system" %host)
2) $ sudo python test.py $host_ip
[whuang@intel-i7-12-4 tmp]$ libvir: RPC error : Cannot recv data: Permission denied, please try again.
Permission denied, please try again.
: Connection reset by peerey,gssapi-keyex,gssapi-with-mic,password).
Traceback (most recent call last):
File "test.py", line 15, in <module>
libvirt.open("qemu+ssh://root@%s/system" %host)
File "/usr/lib64/python2.6/site-packages/libvirt.py", line 236, in open
if ret is None:raise libvirtError('virConnectOpen() failed')
libvirt.libvirtError: Cannot recv data: Permission denied, please try again.
Permission denied, please try again.
: Connection reset by peerey,gssapi-keyex,gssapi-with-mic,password).
BTW,
But maybe this bug is fixed in the libvirt-0.9.4-23.el6.x86_64 or it can not be reproduced ,it will pop up askpass window and can connect successfully in this version with the same steps
(In reply to comment #8)
> But maybe this bug is fixed in the libvirt-0.9.4-23.el6.x86_64 or it can not
> be reproduced ,it will pop up askpass window and can connect successfully in
> this version with the same steps
Based on this comment, I'm marking this BZ as TestOnly and moving to MODIFIED for verification.
Reproduced this issue with libvirt-0.9.3-2.el6.x86_64.
Verified it with:
libvirt-client-0.9.9-0rc1.el6.x86_64
libvirt-python-0.9.9-0rc1.el6.x86_64
libvirt-0.9.9-0rc1.el6.x86_64
Steps:
1.Use a non-root user.
2.[yuping@dhcp-93-226 virsh]$ sudo virt-manager
[sudo] password for yuping:
3.Add a connection to remote host with qemu+ssh://<host-ip>/system
4.Connect to the remote host successfully. No errors pop up.
So change the status to "VERIFIED"
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.
http://rhn.redhat.com/errata/RHSA-2012-0748.html
Description of problem: Unable to open a connection to the libvirt management daemon. Libvirt URI is: qemu+ssh://root.net/system Verify that: - The 'libvirtd' daemon has been started Unable to open connection to hypervisor URI 'qemu+ssh://root.net/system': cannot recv data: No protocol specified (ssh-askpass:22562): Gtk-WARNING **: cannot open display: :0.0 Permission denied, please try again. No protocol specified (ssh-askpass:22563): Gtk-WARNING **: cannot open display: :0.0 Permission denied, please try again. No protocol specified (ssh-askpass:22564): Gtk-WARNING **: cannot open display: :0.0 Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). : Connection reset by peer Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/connection.py", line 992, in _try_open None], flags) File "/usr/lib64/python2.6/site-packages/libvirt.py", line 111, in openAuth if ret is None:raise libvirtError('virConnectOpenAuth() failed') libvirtError: cannot recv data: No protocol specified (ssh-askpass:22562): Gtk-WARNING **: cannot open display: :0.0 Permission denied, please try again. No protocol specified (ssh-askpass:22563): Gtk-WARNING **: cannot open display: :0.0 Permission denied, please try again. No protocol specified (ssh-askpass:22564): Gtk-WARNING **: cannot open display: :0.0 Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). : Connection reset by peer Maybe you need to install ssh-askpass in order to authenticate. [ben@snog tmp]$ rpm -q virt-manager virt-manager-0.8.4-8.el6.noarch The problem seems to be one of access or privileges. Sifting through the log you can see: 22562 execve("/usr/libexec/openssh/ssh-askpass", ["/usr/libexec/openssh/ssh-askpass", "root.net's passw".. .], [/* 23 vars */]) = 0 ... 22562 connect(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, 20) = 0 ... 22562 access("/var/run/gdm/auth-for-ben-JwgDaN/database", R_OK) = -1 EACCES (Permission denied) So what is happening is we exec a process ssh-askpass it tries to connect to the X server but to be able to connect to the screen it needs to get the authority file which ends up being denied for some reason even though the process was run as root. Version-Release number of selected component (if applicable): virt-manager-0.8.6-3.el6.noarch How reproducible: $ sudo virt-manager you can't connect to a remote machines via ssh. The problem seems to have something to do with connecting back to the xserver. however if you do: $ virt-manager you can connect. Actual results: Connection denied. Expected results: Connection succeeds. Additional info: