On 11/16/20 3:46 PM, Peter Krempa wrote:
On Mon, Nov 16, 2020 at 13:20:58 +0100, Michal Privoznik wrote:
> When setting up a new guest or when a management software wants
> to allow access to an existing guest the
> virDomainSetUserPassword() API can be used, but that might be not
> good enough if user want to ssh into the guest. Not only sshd has
> to be configured to accept password authentication (which is
> usually not the case for root), user have to type in their
> password. Using SSH keys is more convenient. Therefore, two new
> APIs are introduced:
>
> virDomainAuthorizedSSHKeysGet() which lists authorized keys for
> given user, and
>
> virDomainAuthorizedSSHKeysSet() which modifies the authorized
> keys file for given user (append, set or remove keys from the
> file).
>
> It's worth nothing that while authorized_keys file entries have
> some structure (as defined by sshd(8)), expressing that structure
> goes beyond libvirt's focus and thus "keys" are nothing but an
> opaque string to libvirt.
>
> Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
> ---
> include/libvirt/libvirt-domain.h | 17 ++++
> src/driver-hypervisor.h | 15 ++++
> src/libvirt-domain.c | 133 +++++++++++++++++++++++++++++++
> src/libvirt_public.syms | 6 ++
> 4 files changed, 171 insertions(+)
[..]
> diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
> index 3c5f55176a..47b821f7d4 100644
> --- a/src/libvirt-domain.c
> +++ b/src/libvirt-domain.c
> @@ -12758,3 +12758,136 @@ virDomainBackupGetXMLDesc(virDomainPtr domain,
> virDispatchError(conn);
> return NULL;
> }
> +
> +
> +/**
> + * virDomainAuthorizedSSHKeysGet:
> + * @domain: a domain object
> + * @user: user to list keys for
> + * @keys: pointer to a variable to store authorized keys
> + * @flags: extra flags; not used yet, so callers should always pass 0
> + *
> + * For given @user in @domain fetch list of public SSH authorized
> + * keys and store them into @keys array which is allocated upon
> + * successful return. The caller is responsible for freeing @keys
> + * when no longer needed.
One nit. We tend to NULL-terminate such lists so that users can use
various checks for iteration.
Ah, good point. I guess it makes sense to NULL terminate only if
actually returning something, i.e. if the retval > 0.
Michal