qemu-devel
[Top][All Lists]
Advanced

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

Re: guest agent public ssh key add/remove support?


From: David Vossel
Subject: Re: guest agent public ssh key add/remove support?
Date: Wed, 19 Aug 2020 09:49:50 -0400



On Tue, Aug 18, 2020 at 3:10 PM Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
On Dienstag, 18. August 2020 15:25:56 CEST David Vossel wrote:
> - Guest Agent SSH add/remove Support?
>
> As a PoC, I cobbled together some guest agent exec and file write client
> commands which can technically achieve the desired result of
> adding/removing entries in a /home/<user>/.ssh/authorized_keys file. It's a
> little unwieldy, but it works.
>
> This got me thinking, an officially supported guest agent api for this ssh
> key management would be really nice. There's already a somewhat related
> precedent with the "guest-set-user-password" guest agent command.
>
> So here's the question. What would you all think about the guest agent API
> being expanded with new commands for adding/removing ssh public keys from
> authorized_keys files?

There are two pass-through file systems in QEMU: 9pfs and virtiofs. Don't you
think they would be sufficient for the use case?

probably not entirely. 

Understand this isn't an either/or scenario. Our api has been designed to support multiple "propagation" methods for the ssh keys. We've converged on the qemu guest agent for some other features and the agent appears to have the potential to provide us the greatest flexibility when it comes to how we want this pub ssh key use case to work.  This isn't to say something like virtiofs won't make sense either in certain scenarios, but for the purposes of this discussion we're hoping to explore how the qemu guest agent could be used.

I don't want to go too deep into the shared filesystem approach. I'll provide some context on the challenges there though.

- virtiofs requires guest kernel >= 5.4. We aren't considering 9p due to security/performance concerns.
- file ownership/permissions. requires prior knowledge of uid/gid on the host.
- persistence. if we share authorised_keys via virtiofs, then we have to put this on a separate persistent network volume (otherwise user modifications within guest are lost)
- potentially clobbers existing authorization_keys file on disk, with agent we can merge our additions/removals to whatever the user has set in authorized_keys.
- lack of KubeVirt support for virtiofs. however, it will likely make it soon




Best regards,
Christian Schoenebeck



reply via email to

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