[Libvir] [PATCH] add no_tty flag for ssh
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 Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Richard W.M. Jones wrote:
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.
I should have added that it is perfectly safe for GUI programs to always add ?no_tty=1 (or &no_tty=1) to the end of URIs. In the non-ssh case it is ignored. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Wed, Sep 12, 2007 at 11:23:58AM +0100, Richard W.M. Jones wrote:
Richard W.M. Jones wrote:
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.
I should have added that it is perfectly safe for GUI programs to always add ?no_tty=1 (or &no_tty=1) to the end of URIs. In the non-ssh case it is ignored.
ACK, fine by me & would make it nicer for virt-manager, as well as for people scripting the CLI tools. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Wed, Sep 12, 2007 at 11:21:29AM +0100, Richard W.M. Jones wrote:
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
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'. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
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. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
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. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
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 ... Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Thu, Sep 20, 2007 at 08:06:22PM +0100, Richard W.M. Jones wrote:
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 ...
Ok, lets commit the no_tty patch then & i'll look at fixing the QEMU driver to parse things properly. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Thu, Sep 20, 2007 at 08:06:22PM +0100, Richard W.M. Jones wrote:
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.
You must have an empty (and not NULL) query field in the xmlURI, which is the reason why xmlSaveURI will dump it. It's needed to preserve empty query strings: paphio:~/XML -> ./testURI http://foo/? http://foo/? paphio:~/XML -> ./testURI http://foo/ http://foo/ paphio:~/XML -> Solution should be to xmlFree the uri->query if empty, and set the field to NULL, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones