I installed virt-manager on a stage3 install with no X server so I could run it over an SSH tunnel. When trying to connect to a remote hypervisor I get the following error message: -------- Unable to open connection to hypervisor URI 'qemu+ssh://root@xxx.xxx.xxx.xxx/system': cannot recv data: ssh_askpass: exec(/usr/lib64/misc/ssh-askpass): No such file or directory ssh_askpass: exec(/usr/lib64/misc/ssh-askpass): No such file or directory ssh_askpass: exec(/usr/lib64/misc/ssh-askpass): No such file or directory Permission denied (publickey,keyboard-interactive). : Connection reset by peer Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/connection.py", line 971, 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: ssh_askpass: exec(/usr/lib64/misc/ssh-askpass): No such file or directory ssh_askpass: exec(/usr/lib64/misc/ssh-askpass): No such file or directory ssh_askpass: exec(/usr/lib64/misc/ssh-askpass): No such file or directory Permission denied (publickey,keyboard-interactive). : Connection reset by peer Maybe you need to install ssh-askpass in order to authenticate. -------- This is resolved by installing something like x11-ssh-askpass. Reproducible: Didn't try Steps to Reproduce: 1. Install stage3. 2. Add keywords for packages enough to install virt-manager. 3. Attempt to connect to remove hypervisor. Actual Results: Error message missing ssh-askpass. Expected Results: Successful connection.
Can you please add the version to the subject?
This isn't an issue in virt-manager. You have SSH_ASKPASS set in your environment but didn't install an askpass provider. So when OpenSSH needs your password to be typed and it sees its running inside of X, instead of a plain terminal session, it will use the graphical ssh-askpass program. Since virt-manager is usable only inside of X, and you used ssh tunneling, you exposed the issue in your config. Now if you don't have SSH_ASKPASS set, there might be an issue that something is setting it.
I did not have SSH_ASKPASS set in my environment (this was a fresh stage-3 install in a kvm). I checked the source for virt-manager and do not see it setting SSH_ASKPASS anywhere either. Can you explain what you mean by: "Since virt-manager is usable only inside of X, and you used ssh tunneling, you exposed the issue in your config." Attached is an output of 'emerge -pv tigervnc virt-manager --emptytree' which does not have any providers of ssh-askpass. So, even if I was not doing SSH tunnel, but doing a real X/VNC session, the requirements would not be installed. I did similar with 'emerge -pv xorg-x11 virt-manager --emptytree'. Looking again I see there is a USE flag for 'gnome-keyring'. Does gnome-keyring provide an ssh-askpass?
Created attachment 235353 [details] Output of emerge --emptytree
Created attachment 235355 [details] Output of emerge --emptytree Was missing "server" USE flag in tigervnc.
virt-manager doesn't use tigervnc, it uses gtk-vnc. gnome-keyring however does manage keys so if you're using a public/private keypair to the machine you're connecting to, it will attempt to prompt you. As far as the comment about using it inside of X, look at the man page for "ssh" and search for SSH_ASKPASS and that'll explain what I meant better. Basically something is telling the ssh application that it should prompt for password via graphical means and it is unable to. I don't have x11-ssh-askpass or ssh-askpass-fullscreen installed and this is working ok for me. Real reason I'm hesitant here is the second I add this dep, someone will open a ticket that its unnecessary.
I haven't had a chance to get back to this until today. I understand the desire to keep the depends to a minimum but I also expect packages to either "work" or display a message when I install them as to additional packages I might find useful for functionality (as libvirt does). I don't believe what I am doing is out of the ordinary for a server environment, which is what I'm setting up. I have installed a very minimal system, with kvm and libvirt and no network direct access, to act as a hypervisor layer. I have installed a VM on top of this, which I also want to keep as minimal as possible, with just virt-manager in it. I am then using this virtual machine to create and manage other virtual machines with VT-d and being used to physically separate the networks of the virtual machines. What I find is that 'emerge virt-manager' on top of a plain non-X stage3 does not work out-of-the-box to communicate with the hypervisor. It needs some sort of SSH authentication assistance, which I satisfied with x11-ssh-askpass. Some sort of warning during install or dependancy check seems better then the user, me in this case, having to track down what the error message means. I understand what I am doing is advanced and debug is expected, but I'm just trying to improve the situation for those who come after. I realize that if I had installed a full gnome environment that this would have probably worked. Virt-manager doesn't require gnome either (other than gtk) and it shouldn't. Packages should work for server, non-X11, environments though. With regard to your comment about gtk-vnc, virt-manager uses gtk-vnc to display the remote clients. Gtk-vnc does not have a X11 server with it. I want to use either SSH X forwarding or VNC to display virt-manager because this is a headless machine. I also tried to install virt-manager with the gnome-keyring USE flag on, as suggested, and this did not improve anything. In fact, turning on this causes virt-manager to not even start up initially because something is missing a check for dbus with +X use. After fixing dbus, virt-manager still has the ssh-askpass issue. Let me reiterate my concerns: * virt-manager will not connect to remote hypervisors, over SSH tunnel, on headless machines without additionally installing an ssh-askpass provider AND the virt-manager package does not depend on or give an informational warning at install. * virt-manager with +gnome-keyring requires dbus to be installed with +X but will install without the check. virt-manager fails to start without this. This may be an issue with a package virt-manager depends on (one of the python bindings?) and not virt-manager. I can open another bug for this if desired.
(In reply to comment #7) > > Let me reiterate my concerns: > > * virt-manager will not connect to remote hypervisors, over SSH tunnel, on > headless machines without additionally installing an ssh-askpass provider AND > the virt-manager package does not depend on or give an informational warning at > install. Again, virt-manager doesn't need this. Your ssh-agent stand-in application needs this. Whatever you've got wired up as the stand-in for that needs ssh-askpass. I use keychain and it works just fine for me everytime. I don't have either of the two ssh-askpass applications installed. Figure out what you're using for SSH key management in your desktop and complain to that package maintainer.
Are you saying this is a problem with the desktop where I am remote-displaying virt-manager or the "desktop" where virt-manager is running? As I said, I'm running virt-manager on a headless server X-forwarded over SSH. I looked through the ssh man page on agent forwarding and don't see anything obvious I'm missing on the display-desktop side, but if that's where you believe the problem is I'll keep investigating.
(In reply to comment #8) > Again, virt-manager doesn't need this. Your ssh-agent stand-in application > needs this. Whatever you've got wired up as the stand-in for that needs > ssh-askpass. I use keychain and it works just fine for me everytime. I don't > have either of the two ssh-askpass applications installed. Figure out what > you're using for SSH key management in your desktop and complain to that > package maintainer. > Using virt-manager on KDE comes pre-broken. I have no SSH-ASKPASS set in the env, so this funny little app seems to have a hardcoded fallback on ssh-askpass. Which of course is not installed, so connecting just silently fails. BAD MONKEY! I'd say this automagic / hardwired dep should be made explicit, or at least some pretty strong postinstall hints so that people don't have to debug why it fails out of the box.
I just hit this issue on my KDE box when trying to connect to a remote hypervisor. I don't have SSH-ASKPASS set. I also don't know what is supposed to set it. I agree with Patrick that we should at least have a post install message. It certainly would have saved me some time.
This is an issue with people building net-misc/openssh with USE=X and not having an askpass application installed. Anytime the ssh command is used when USE=X is set and no tty is available, it will use an askpass application. Again, absolutely nothing to do with virt-manager.
funny, virt-manager already gives you an explicit tip as to what you need to fix the situation. i dont think adding an elog to the ebuild would make any difference at all to users who dont read the error thrown up at them. there are many ssh-askpass providers in the tree, and picking a single one will make someone whine. someone probably will have to slap a virtual/ssh-askpass together than considers the various USE settings to pull in the relevant packages and then openssh can simply use that.
(In reply to comment #12) > Anytime the ssh command is used when USE=X is set and no tty is available, it > will use an askpass application. Thank you for clearing this up. 'equery uses openssh' prints a generic description so I had no idea what USE=X did for openssh. (In reply to comment #13) > funny, virt-manager already gives you an explicit tip as to what you need to > fix the situation. i dont think adding an elog to the ebuild would make any > difference at all to users who dont read the error thrown up at them. I did read the error from virt-manager. I just incorrectly assumed that it would have provided the needed package to work.
*** Bug 383603 has been marked as a duplicate of this bug. ***
To solve: emerge net-misc/ssh-askpass-fullscreen env-update . /etc/profile o logout
*** Bug 511692 has been marked as a duplicate of this bug. ***
