[libvirt] [PATCH 0/1] qemu: Add Secure Shell (ssh) network block device.

[Daniel P. Berrange]

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 :|