Re: [Qemu-block] [Qemu-devel] Whither qemu's ssh driver?

[Markus Armbruster]

Max Reitz <address@hidden> writes:

> On 08.04.19 19:22, Richard W.M. Jones wrote:
>> 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.
>
> I don’t disagree with anything you say.  I would prefer to move the less
> well maintained drivers (for which there is no strict performance
> requirement) into a separate process.  nbdkit is perfectly suited for
> that, and the drivers are there, as you say (ssh, curl, vvfat).
>
> Having a nicer interface in qemu would make the transition simple,
> because we could tell users exactly how to change their command line so
> their use case continues to work.  I’m not sure whether it really works,
> though, because I don’t think there is such a simple replacement for
> being able to simply pass "ssh://host/path" to qemu and have it work.
>
> But I think it’s still worth it.

I guess that boils down to "patches welcome".

For v1, I wouldn't worry about making the transition simple.  Just show
us some working code.