On Wed, Apr 10, 2013 at 03:09:18PM +0100, Richard W.M. Jones wrote: > This patch allows you to use the qemu Secure Shell (ssh) block device. > This is not upstream yet, but you can find my latest version here: > > http://lists.nongnu.org/archive/html/qemu-devel/2013-04/threads.html#01703 > > This patch lets you specify a ssh device like this: > > <disk type='network' device='disk'> > <source protocol='ssh' name='/remote/path/to/disk/image'> > <host name='remote-server.example.com'/> > </source> Ok, looks sensible. > <driver name='qemu' type='raw'/> > <target dev='vda' bus='virtio'/> > </disk> > > Patched qemu will connect to remote-server.example.com using libssh2, > and access /remote/path/to/disk/image using the sftp protocol. This > works for both read and write. > > Of course, since you'll have to use a patched qemu, you will also need > to fiddle with the <emulator> setting. > > One current problem with this patch is that you have to manually set > the SSH_AUTH_SOCK environment variable to point at your ssh-agent > (since qemu's ssh block device requires ssh-agent authentication). I > added the following to my XML, your value will be different: > > <qemu:commandline> > <qemu:env name="SSH_AUTH_SOCK" value="/tmp/ssh-DThteVfEeOq3/agent.1773" /> > </qemu:commandline> Hmm, yes, that's a big problem, particularly from an sVirt POV. You certainly do not want a compromised QEMU to be able to use the SSH agent to obtain your keys for logging into arbitrary remote systems. So exposing the SSH agent to QEMU directly seems like a no-go. > Some shortcomings: > > - Does not allow you to specify the host_key_check parameter. > > - No tests. > > - 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. > - I did not test if you can specify an alternate remote user. > > - I did not test (or care) if parsing qemu command lines works. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list