qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-block] Whither qemu's ssh driver? (was: Re: [PATCH 02/15] block/ss


From: Richard W.M. Jones
Subject: [Qemu-block] Whither qemu's ssh driver? (was: Re: [PATCH 02/15] block/ssh: Do not report read/write/flush errors to the user)
Date: Mon, 8 Apr 2019 18:22:11 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

I don't know much about this patch which looks like internal qemu
rearrangements so I guess fine.  However I do have a few things to say
about the ssh driver ...

As you know I wrote this a few years ago, and it uses libssh2.
libssh2 has not evolved as quickly as we'd like and it may be better
to use libssh instead -- despite the names, these are two separate and
unrelated libraries.  libssh supports a wider range of SSH encryption
and has more features.  It's generally more likely to work against a
random SSH server.  It has also been through the FIPS process.  Indeed
Red Hat made the decision to switch exclusively to libssh in RHEL 8,
if that carries any weight.

Pino posted a libssh2 -> libssh conversion patch a while back, but it
has been somewhat stuck in review.  If I recall the latest concern was
whether it performs as well as the libssh2 version.

  https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg07267.html

In the meantime I added libssh support to nbdkit.  nbdkit can be used
as a complete replacement for qemu's ssh driver.

  nbdkit ssh host=foo.example.com disk.img -U tmpdirXXXXXX/sock
  qemu -hda nbd:unix:tmpdirXXXXXX/sock

In fact it's somewhat superior (IMHO) because all of the tricky code
handling libssh runs outside qemu in a separate process, improving
isolation and potentially allowing separate, restrictive security
policies to be applied.  For example it would no longer be necessary
to give qemu permission to connect to remote SSH servers.

Could we make this really smooth somehow?  nbdkit has a concept
[https://www.mankier.com/1/nbdkit-captive] where we make it easy to
manage external commands owned by nbdkit.  Is there an equivalent
feature of qemu where:

  qemu -object exec,id=nbd1,cmd='nbdkit -f -U $sock ssh ...' \
       -drive file.driver=nbd,file.socket=nbd1

would run the command but also allocate a socket and kill the
subcommand on exit (of qemu)?

Basically I'm trying to think about how to make this a reality:

  https://rwmj.files.wordpress.com/2018/10/drawing2-svg.png

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW



reply via email to

[Prev in Thread] Current Thread [Next in Thread]