On 2/16/23 10:43 AM, Peter Krempa wrote:
On Tue, Feb 14, 2023 at 11:08:14 -0600, Jonathon Jongsma wrote:
> Right now, ssh network disks are not usable. There is some basic support
> in libvirt that is meant to support disk chains that have backing disks
> located at ssh urls, but there is no real way for a user to configure a
> ssh-based disk. This commit allows users to configure an ssh disk with
> password authentication. Implementation will follow.
>
> <disk type='network'>
> <source protocol='ssh' ...>
> <auth username='myusername'>
> <secret type='iscsi' usage='secretname'/>
> </auth>
> </disk>
>
> Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com>
> ---
> docs/formatdomain.rst | 27 ++++++++++++++-------------
> src/conf/schemas/domaincommon.rng | 23 ++++++++++++++++++++++-
> 2 files changed, 36 insertions(+), 14 deletions(-)
>
> diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
> index 36c6d87907..bf071255c5 100644
> --- a/docs/formatdomain.rst
> +++ b/docs/formatdomain.rst
> @@ -2718,7 +2718,7 @@ paravirtualized driver is specified via the ``disk`` element.
> ``network``
> The ``protocol`` attribute specifies the protocol to access to the
> requested image. Possible values are "nbd", "iscsi",
"rbd", "sheepdog",
> - "gluster", "vxhs", "nfs", "http",
"https", "ftp", ftps", or "tftp".
> + "gluster", "vxhs", "nfs", "http",
"https", "ftp", ftps", "tftp", or "ssh".
>
> For any ``protocol`` other than ``nbd`` an additional attribute ``name``
> is mandatory to specify which volume/image will be used.
> @@ -2870,18 +2870,19 @@ paravirtualized driver is specified via the ``disk``
element.
> ``auth``
> :since:`Since libvirt 3.9.0` , the ``auth`` element is supported for a
> disk ``type`` "network" that is using a ``source`` element with
the
> - ``protocol`` attributes "rbd" or "iscsi". If present, the
``auth`` element
> - provides the authentication credentials needed to access the source. It
> - includes a mandatory attribute ``username``, which identifies the username
> - to use during authentication, as well as a sub-element ``secret`` with
> - mandatory attribute ``type``, to tie back to a `libvirt secret
> - object <formatsecret.html>`__ that holds the actual password or other
> - credentials (the domain XML intentionally does not expose the password,
> - only the reference to the object that does manage the password). Known
> - secret types are "ceph" for Ceph RBD network sources and
"iscsi" for CHAP
> - authentication of iSCSI targets. Both will require either a ``uuid``
> - attribute with the UUID of the secret object or a ``usage`` attribute
> - matching the key that was specified in the secret object.
> + ``protocol`` attributes "rbd", "iscsi", or
"ssh". If present, the
> + ``auth`` element provides the authentication credentials needed to access
> + the source. It includes a mandatory attribute ``username``, which
> + identifies the username to use during authentication, as well as a
> + sub-element ``secret`` with mandatory attribute ``type``, to tie back to
> + a `libvirt secret object <formatsecret.html>`__ that holds the actual
> + password or other credentials (the domain XML intentionally does not
> + expose the password, only the reference to the object that does manage
> + the password). Known secret types are "ceph" for Ceph RBD network
sources
> + and "iscsi" for CHAP authentication of iSCSI targets. Both will
require
> + either a ``uuid`` attribute with the UUID of the secret object or a
> + ``usage`` attribute matching the key that was specified in the secret
> + object.
This paragraph doesn't really state what to put into 'type' for ssh as
'ceph' and 'iscsi' are only mentioned. For 'ssh' we need a
'ssh' type.
Hmm, do we also need a separate type for http auth as well, then? At the
moment we seem to just re-use the 'iscsi' type for all of the http auth
in our tests (e.g. disk-cdrom-network.xml, etc).
This will also tie nicely in case you want to do ssh key authentication
with encrypted key, where you can pass the key via a different type
'ssh-key' or something like that to unlock the key.