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?

The SSH client should not need to elevate its privileges on the client side, so blocking any setuid() usage is a desirable feature IMHO.

Upstream discussion:

http://www.redhat.com/archives/libvir-list/2011-July/msg01694.html

Not sure of any way to solve this issue without preserving capabilities, so back to the drawing board I guess.

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