Pino Toscano <ptosc...@redhat.com> writes: > On Monday, 29 July 2019 12:57:40 CEST Markus Armbruster wrote: >> Pino Toscano <ptosc...@redhat.com> 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 <ptosc...@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? >> > >> > 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?