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

[David Vossel <dvossel@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2348 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3154 bytes --]