All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: pkrempa@redhat.com, qemu-block@nongnu.org, qemu-devel@nongnu.org,
	Markus Armbruster <armbru@redhat.com>,
	rjones@redhat.com, mreitz@redhat.com,
	Pino Toscano <ptoscano@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 2/2] ssh: implement private key authentication
Date: Mon, 29 Jul 2019 13:08:30 +0200	[thread overview]
Message-ID: <20190729110830.GA5757@localhost.localdomain> (raw)
In-Reply-To: <549f94df-5d31-3dfe-0693-72a2861ddd7f@redhat.com>

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

Am 26.07.2019 um 16:24 hat Eric Blake geschrieben:
> On 7/26/19 9:09 AM, Pino Toscano wrote:
> > Add a 'private-key' option which represents the path of a private key
> > to use for authentication, and 'private-key-secret' as the name of an
> > object with its passphrase.
> > 
> > Signed-off-by: Pino Toscano <ptoscano@redhat.com>
> 
> > +++ b/qapi/block-core.json
> > @@ -3226,6 +3226,11 @@
> >  # @password-secret:     ID of a QCryptoSecret object providing a password
> >  #                       for authentication (since 4.2)
> >  #
> > +# @private-key:         path to the private key (since 4.2)
> > +#
> > +# @private-key-secret:  ID of a QCryptoSecret object providing the passphrase
> > +#                       for 'private-key' (since 4.2)
> 
> Is password-secret intended to be mutually-exclusive with
> private-key/private-key-secret?  If so, this should probably utilize an
> enum for a discriminator
> { 'enum': 'SshAuth', 'data': ['ssh-agent', 'password', 'private'key'] }
> 
> then update BlockdevOptionsSsh to be a union type with an optional
> discriminator (defaulting to ssh-agent) for back-compat, where
> 'auth':'ssh-agent' needs no further fields, 'auth':'password' adds in a
> 'secret' field for use as password, or where 'auth':'private-key' adds
> in both 'key-file' and 'secret' for use as the two pieces needed for
> private key use.

Can we actually support optional discriminators when we don't have
defaults in the QAPI schema yet?

> On a different topic, how much of this work overlaps with the nbdkit ssh
> plugin? Should we be duplicating efforts with both projects supporting
> ssh natively, or is it worth considering getting qemu out of the ssh
> business and instead connecting to an nbd device provided by nbdkit
> connecting to ssh?

ssh behaves essentially like a filesystem whereas NBD behaves like a
block device. This is especially relevant for everything related to the
file size. As far as I know, using an image format like qcow2 that wants
to grow the image file isn't possible over NBD, whereas I expect it to
work with the ssh block driver.

Kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

  parent reply	other threads:[~2019-07-29 11:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-26 14:09 [Qemu-devel] [PATCH 0/2] ssh: add password and privkey auth methods Pino Toscano
2019-07-26 14:09 ` [Qemu-devel] [PATCH 1/2] ssh: implement password authentication Pino Toscano
2019-07-26 14:09 ` [Qemu-devel] [PATCH 2/2] ssh: implement private key authentication Pino Toscano
2019-07-26 14:24   ` Eric Blake
2019-07-26 14:29     ` Richard W.M. Jones
2019-07-29  8:00     ` Pino Toscano
2019-07-29 10:57       ` Markus Armbruster
2019-07-29 11:21         ` Pino Toscano
2019-07-29 15:10           ` Markus Armbruster
2019-07-29 11:08     ` Kevin Wolf [this message]
2019-08-12 21:08       ` Max Reitz
2019-08-12 21:22       ` Eric Blake
2019-07-26 14:27 ` [Qemu-devel] [PATCH 0/2] ssh: add password and privkey auth methods Richard W.M. Jones
2019-07-26 14:45   ` Pino Toscano
2019-07-26 14:50     ` Richard W.M. Jones
2019-07-26 15:06     ` Eric Blake
2019-07-26 15:35       ` Richard W.M. Jones
2019-07-26 15:43         ` Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190729110830.GA5757@localhost.localdomain \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pkrempa@redhat.com \
    --cc=ptoscano@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.