This patch adds an extra no_tty=1 flag to the connection URI. This stops ssh from asking for a password if it can't log in automatically. Typical use-case for this is in graphical programs where if ssh asks for a password it would cause the GUI program to hang.

This patch adds an extra no_tty=1 flag to the connection URI. This stops ssh from asking for a password if it can't log in automatically. Typical use-case for this is in graphical programs where if ssh asks for a password it would cause the GUI program to hang. Example: $ virsh -c xen+ssh://xxx/ list rjones@xxx's password: Permission denied, please try again. rjones@xxx's password: Permission denied, please try again. rjones@xxx's password: Permission denied (publickey,gssapi-with-mic,password). libvir: Remote error : Connection reset by peer error: failed to connect to the hypervisor error: no valid connection $ virsh -c xen+ssh://xxx/?no_tty=1 list Permission denied (publickey,gssapi-with-mic,password). libvir: Remote error : Connection reset by peer error: failed to connect to the hypervisor error: no valid connection

Daniel P. Berrange wrote: >The use of '-o PasswordAuthentication=no' isn't sufficient because even >with pulic key / gssapi auth schemes it may prompt for passwords and/or >passphrases. > >I think we need to use '-T -o BatchMode=yes', and regardless of the >no_tty flag I think it could be wise to add '-e none'. Yes, that's right. Try this patch.

Daniel P. Berrange wrote: >On Thu, Sep 20, 2007 at 01:10:28PM +0100, Richard W.M. Jones wrote: >>Daniel P. Berrange wrote: >>>The use of '-o PasswordAuthentication=no' isn't sufficient because even >>>with pulic key / gssapi auth schemes it may prompt for passwords and/or >>>passphrases. >>> >>>I think we need to use '-T -o BatchMode=yes', and regardless of the >>>no_tty flag I think it could be wise to add '-e none'. >>Yes, that's right. Try this patch. > >There's something not quite right going on. It correctly prevents the >prompting of passwords, but the '?' seems to be passed through to the >remote end. So the server side tries to open 'qemu:///system?' and >fails. > >Now technically '?' is a valid URI character and so qemu_driver.c should >handle it, by parsing the URI properly, rather than STREQ(qemu:///system), >but I think the client side should avoid appending the '?' too if there is >no parameter to pass across. The URI is reconstructed using xmlSaveUri from libxml2, and as far as I can see that always appends a '?' character. The logic of remote_internal.c has got rather convoluted since qemu support was added so I can't see why this doesn't hit us in the current code, but it certainly hits us now. Only way I can see around this is to write proper URI parsing into qemu_driver.c ...