On Mon, Apr 15, 2013 at 11:11:10AM +0100, Daniel P. Berrange wrote: > On Wed, Apr 10, 2013 at 03:09:18PM +0100, Richard W.M. Jones wrote: > > - Not sure how best to deal with the ssh-agent authentication socket > > problem. Use libvirt secrets? If so, how? > > The way that works, is that the application creating the guest > has to pre-populate secrets with keys/passwords/whatever. The > guest XML refers to which secrets it needs, and at guest startup > Libvirt would push the secrets into QEMU. > > IIUC, the SSH agent protocol is fundamentally designed around the > idea of "application pull", where as we want an approach which I > describe as "manager push". > > Using secrets for passing authentication information in for disks > is the right thing todo - we already do this for RBD for example. > What is missing is a way to securely pass this into QEMU - for RBD > we currently pass this on the command line. The guys who added RBD > support to libvirt were supposed to be adding ability to pass the > passwords via the monitor but that never seems to have happened. > I wish we'd never allowed the patches for RBD for passing stuff on > the command line, still it removed the motivation for them todo a > better job. > > Anyway for SSH, I think we need to have this bit of QEMU finished, > so we can pass in authentication credentials via the monitor. There > is an existing 'block_password' command, but that was used for the > decryption keys and I don't think it is wise to overload that for > authentication keys too, since it is in theory possible to access > an encrypted QCow2 image over the SSH protocol, in which case we > would need both decryption keys and authetnication keys at the same > time. > > The only other alternative would be to actally make libvirtd implement > an SSH agent service, exposing per-VM UNIX to the QEMU process(es) which > needed SSH keys. I don't much like this though, since it would only > be useful to the SSH disk protocol, and not help address the problems > we already face for RBD and other network block devices. Would this be any easier if we implemented password authentication (in qemu's ssh block driver). Then the secret stored by libvirt would be the password, which it could pass to qemu. There is still the question of overloading the block_password monitor command, but that problem presumably applies to other drivers as well. In fact, you seem to have summarised the solution (I assume this was never implemented) back in 2011: http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02495.html Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list