Re: [Qemu-devel] [PATCH 2/2] ssh: implement private key authentication
On 29.07.19 13:08, Kevin Wolf wrote: > 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 >> >>> +++ 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? Just chiming in here, because I wanted to throw in that v4 of my “block: Try to create well-typed json:{} filenames” series adds that. >> 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. Just using sshfs and file-posix would seem simpler to me, by the way. Max signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 2/2] ssh: implement private key authentication
On 7/29/19 6:08 AM, Kevin Wolf wrote: >> 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. Resizing NBD devices isn't available yet, but it is rapidly moving higher on my list of TODO items to implement as an extension (the ideas for how it should work have been tossed around, but having code to back up those ideas is the next step). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 2/2] ssh: implement private key authentication
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 > +++ 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. Markus may have other suggestions on how best to represent this sort of union type in QAPI. > +# > # Since: 2.9 > ## > { 'struct': 'BlockdevOptionsSsh', > @@ -3233,7 +3238,9 @@ > 'path': 'str', > '*user': 'str', > '*host-key-check': 'SshHostKeyCheck', > -'*password-secret': 'str' } } > +'*password-secret': 'str', > +'*private-key': 'str', > +'*private-key-secret': 'str' } } > > > ## > 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? (For comparison, we've already decided that nbdkit does not plan on writing a qcow2 plugin, because it defers to qemu to be the expert there; or in the other direction, qemu-nbd has deprecated its partial support for exposing only a partition of a disk in favor of qemu-nbd having much more partition support through its filters) -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 2/2] ssh: implement private key authentication
On Fri, Jul 26, 2019 at 09:24:34AM -0500, Eric Blake wrote: > 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? (For comparison, we've already decided that nbdkit > does not plan on writing a qcow2 plugin, because it defers to qemu to be > the expert there; or in the other direction, qemu-nbd has deprecated its > partial support for exposing only a partition of a disk in favor of > qemu-nbd having much more partition support through its filters) I think it would be good if libvirt could handle this usage, so it would set up the nbdkit process, set up seccomp or SELinux to confine it, and kill nbdkit afterwards. See also: https://rwmj.wordpress.com/2018/10/30/split-block-drivers-from-qemu-with-nbdkit/ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
Re: [Qemu-devel] [PATCH 2/2] ssh: implement private key authentication
On Friday, 26 July 2019 16:24:34 CEST Eric Blake wrote: > 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 > > > +++ 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? My initial thought was to allow users to specify data for all the authentication methods possible. Either ways (all of them, or a single one) are fine for me. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: [Qemu-devel] [PATCH 2/2] ssh: implement private key authentication
Pino Toscano writes: > On Friday, 26 July 2019 16:24:34 CEST Eric Blake wrote: >> 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 >> >> > +++ 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? > > My initial thought was to allow users to specify data for all the > authentication methods possible. Either ways (all of them, or a single > one) are fine for me. How does this work at the libssh level? Can you configure multiple authentication methods, and let negotiation pick the one to be used?
Re: [Qemu-devel] [PATCH 2/2] ssh: implement private key authentication
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 > > > +++ 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 signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH 2/2] ssh: implement private key authentication
On Monday, 29 July 2019 12:57:40 CEST Markus Armbruster wrote: > Pino Toscano writes: > > > On Friday, 26 July 2019 16:24:34 CEST Eric Blake wrote: > >> 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 > >> > >> > +++ 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? > > > > My initial thought was to allow users to specify data for all the > > authentication methods possible. Either ways (all of them, or a single > > one) are fine for me. > > How does this work at the libssh level? Can you configure multiple > authentication methods, and let negotiation pick the one to be used? The remote servers sends all the authentication methods supported, and the user of libssh can decide which one(s) to attempt. See for example the small tutorial in the libssh documentation: http://api.libssh.org/stable/libssh_tutor_authentication.html -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: [Qemu-devel] [PATCH 2/2] ssh: implement private key authentication
Pino Toscano writes: > On Monday, 29 July 2019 12:57:40 CEST Markus Armbruster wrote: >> Pino Toscano writes: >> >> > On Friday, 26 July 2019 16:24:34 CEST Eric Blake wrote: >> >> 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 >> >> >> >> > +++ 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? >> > >> > My initial thought was to allow users to specify data for all the >> > authentication methods possible. Either ways (all of them, or a single >> > one) are fine for me. >> >> How does this work at the libssh level? Can you configure multiple >> authentication methods, and let negotiation pick the one to be used? > > The remote servers sends all the authentication methods supported, and > the user of libssh can decide which one(s) to attempt. See for example > the small tutorial in the libssh documentation: > http://api.libssh.org/stable/libssh_tutor_authentication.html SSH server and client negotiate: the server offers methods, the client tries offered methods it likes one after the other. This means we want QMP to let us configure which methods we like, along with whatever data is necessary to actually try them. In short, we don't want mutually exclusive here. Correct?