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

[Daniel P. Berrange]

On Mon, Apr 15, 2013 at 12:18:43PM +0100, Richard W.M. Jones wrote:
> On Mon, Apr 15, 2013 at 11:31:08AM +0100, Daniel P. Berrange wrote:
> > Yep, that would make it easier. Also if you did SSH key auth, but allowed
> > passphrases to be passed in, instead of pulled from an agent (in same way
> > SSH does if no agent is running).
> 
> Because qemu is running as a different user (qemu.qemu) it most likely
> won't have access to $HOME/.ssh/id_rsa, even assuming it knew which
> $HOME to go to.

True, and actally we'd be blocking access to that file with sVirt
anyway.

> For ssh key auth, it would be helpful if both the raw key file
> contents and the passphrase could be stored as libvirt secrets.  Is
> that possible?

That would imply multiple secrets, but yes, it should be possible.

> If so, qemu can pass both to libssh2_userauth_publickey.  Almost as in
> this example: http://libssh2.org/examples/ssh2.html , combined with
> looking at how libssh2_userauth_publickey_fromfile is implemented:
> 
> http://git.libssh2.org/?p=libssh2.git;a=blob;f=src/userauth.c;h=a0733d5da05ff7b3656e915e503665b63c82111f;hb=HEAD#l1214
> 
> I'm also a bit concerned that the solution should be usable for
> ordinary users.  qemu -drive file=ssh://... currently Just Works.

If you want "just works" then you don't really want to have the
separate "load credentials into libvirt" step that using the
secrets APIs implies. This pretty much says you need to let it
use the SSH agent. You don't want to be including the SSH agent
socket path in the XML though, since that is randomly generated
on each login. In the session libvirtd instance, libvirtd iself
will already see the SSH agent socket, so could just whitelist
the SSH_AUTH_SOCK env variable when starting QEMU.

For system libvirtd, I think connecting to the user's SSH
agent is a dead end, because we can't assume the 'qemu' user
has access to the SSH agent socket - beyond file permissions,
/tmp can be in a separate namespace, so qemu can't even assume
to see the same /tmp as the user does.

> - How should host_key_check be modelled via the libvirt XML / API?

I'm not sure - what does that do ?

> - We want the user to be able to select different authentication
>   methods (at least, password, publickey, agent [insecurely]).  How
>   would you see these being modelled in the API?  Particularly since
>   these may require associated secret(s).

Well for password/publickey the existance of the neccessary secrets
in the XML will indicate whether each of them can be enabled. Not
sure what to suggest for the ssh agent though.

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