Re: [libvirt PATCH v5 27/32] schema: add password configuration for ssh disk

[Jonathon Jongsma]

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 <jjong...@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.