Libguestfs - Jul 2022 - [v2v PATCH 2/2] input-xen: replace "enable LEGACY crypto" advice with targeted ssh options

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1854275
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2062360

The input-xen documentation currently recommends a system-wide crypto
policy downgrade (to LEGACY) for connecting to RHEL5 sshd. Replace the
recommendation with the individual ssh options that enable this kind of
connection.

While investigating this (for RHBZ#2062360), I found that, for
RHBZ#1854275, I had missed a call chain in virt-v2v where libvirt
launched "ssh", and therefore the "-ip" option would be
relevant.
Because "-ip" does not work there, first copy the respective caveat
from
the input-vmware documentation to input-xen.

Thanks
Laszlo

Laszlo Ersek (2):
  input-xen: sync "-ip" limitations language from input-vmware manual
  input-xen: replace "enable LEGACY crypto" advice with targeted ssh
    options

 docs/virt-v2v-input-xen.pod | 25 ++++++++++++++++----
 1 file changed, 20 insertions(+), 5 deletions(-)

-- 
2.19.1.3.g30247aa5d201

My analysis in <https://bugzilla.redhat.com/show_bug.cgi?id=1854275#c33>
was partially wrong; I had missed that for the xen+ssh transport, the
client-side libvirt library launches a naked "ssh" utility, underneath
"Libvirt.Connect.connect_auth":

  setup                            [input/input_xen_ssh.ml]
    Libvirt.Connect.connect_auth
      no effect of "-ip"
    Nbdkit_ssh.create_ssh          [input/nbdkit_ssh.ml]
      starts nbdkit with the ssh
        plugin honoring "-ip"

Which requires a password just the same, and ignores "-ip" just the
same.

Recommend the ssh agent in the docs.

Fixes: 46298c6514710013c59828b4933f0b3b1a354566
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1854275
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2062360
Signed-off-by: Laszlo Ersek <lersek at redhat.com>
---
 docs/virt-v2v-input-xen.pod | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/docs/virt-v2v-input-xen.pod b/docs/virt-v2v-input-xen.pod
index 8080ebea7723..afc4a019f13d 100644
--- a/docs/virt-v2v-input-xen.pod
+++ b/docs/virt-v2v-input-xen.pod
@@ -32,6 +32,11 @@ server to the Xen host.  For example:
  $ ssh root at xen.example.com
  [ logs straight into the shell, no password is requested ]
 
+Note that support for non-interactive authentication via the I<-ip>
+option is incomplete.  Some operations remain that still require the
+user to enter the password manually.  Therefore ssh-agent is recommended
+over the I<-ip> option.  See
L<https://bugzilla.redhat.com/1854275>.
+
 With some modern ssh implementations, legacy crypto policies required
 to interoperate with RHEL 5 sshd are disabled.  To enable them you may
 need to run this command on the conversion server (ie. ssh client),
-- 
2.19.1.3.g30247aa5d201

- "KexAlgorithms": the Fedora 35 ssh binary, using the DEFAULT
  crypto-policy, cannot log in to RHEL5 sshd without relaxing
  "KexAlgorithms". The server offers three algorithms:
  "diffie-hellman-group-exchange-sha1",
"diffie-hellman-group14-sha1",
  "diffie-hellman-group1-sha1"; and according to RFC 9142,
  "diffie-hellman-group14-sha1" is the least deprecated from those.
(The
  RFC marks it as MAY be implemented, and marks the other two as SHOULD
  NOT be implemented.) Recommend "diffie-hellman-group14-sha1".

- "MACs": the Fedora 35 ssh binary, using the FUTURE crypto-policy,
cannot
  log in to RHEL5 sshd without relaxing "MACs". The server offers
  "hmac-md5", "hmac-sha1", "hmac-ripemd160",
"hmac-ripemd160 at openssh.com",
  "hmac-sha1-96", "hmac-md5-96". After eliminating the
MD5-based algos
  (MD5 is considered completely broken), and the one based on truncated
  SHA1, we're left with "hmac-sha1", "hmac-ripemd160",
and
  "hmac-ripemd160 at openssh.com". RIPEMD-160 is generally trusted,
but it is
  compiled out of the Fedora 35 "ssh" client binary. Therefore only
  "hmac-sha1" remains.

- "HostKeyAlgorithms", "PubkeyAcceptedAlgorithms": these
options control
  the usage of public key algorithms, for authenticating the server to the
  client, and vice versa, respectively. RHEL5 sshd only supports
"ssh-rsa"
  and "ssh-dss", and from those, "ssh-rsa" is more commonly
used (for
  example, "ssh-keygen" defaults to creating "ssh-rsa"
keys). Recommend
  "ssh-rsa".

- "PubkeyAcceptedKeyTypes": this is the old ("legacy") name
for
  "PubkeyAcceptedAlgorithms". As of this writing, the latest upstream
  release of libssh (also packaged in Fedora 35 -- libssh-0.9.6-1.fc35)
  does not recognize the new "PubkeyAcceptedAlgorithms" option name,
only
  the original "PubkeyAcceptedKeyTypes". openssh-8.7p1-3.fc35
recognizes
  both option variants. Include "PubkeyAcceptedKeyTypes" in the
  recommendation along with "PubkeyAcceptedAlgorithms", for backward
and
  forward compatbility.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2062360
Signed-off-by: Laszlo Ersek <lersek at redhat.com>
---
 docs/virt-v2v-input-xen.pod | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/docs/virt-v2v-input-xen.pod b/docs/virt-v2v-input-xen.pod
index afc4a019f13d..789853b4d194 100644
--- a/docs/virt-v2v-input-xen.pod
+++ b/docs/virt-v2v-input-xen.pod
@@ -37,12 +37,22 @@ option is incomplete.  Some operations remain that still
require the
 user to enter the password manually.  Therefore ssh-agent is recommended
 over the I<-ip> option.  See
L<https://bugzilla.redhat.com/1854275>.
 
-With some modern ssh implementations, legacy crypto policies required
-to interoperate with RHEL 5 sshd are disabled.  To enable them you may
-need to run this command on the conversion server (ie. ssh client),
-but read L<update-crypto-policies(8)> first:
+With some modern ssh implementations, legacy crypto algorithms required
+to interoperate with RHEL 5 sshd are disabled.  To enable them, you may
+need to add the following C<Host> stanza to your F<~/.ssh/config>:
 
- # update-crypto-policies --set LEGACY
+ Host xen.example.com
+   KexAlgorithms            +diffie-hellman-group14-sha1
+   MACs                     +hmac-sha1
+   HostKeyAlgorithms        +ssh-rsa
+   PubkeyAcceptedKeyTypes   +ssh-rsa
+   PubkeyAcceptedAlgorithms +ssh-rsa
+
+(C<PubkeyAcceptedKeyTypes> and C<PubkeyAcceptedAlgorithms> have
+identical meaning; the former is the old option name, the latter is the
+new one. Virt-v2v uses both C<libssh> and C<ssh> when converting a
guest
+from Xen, and on some operating systems, C<libssh> and C<ssh> may
not
+both accept the same option variant.)
 
 =head2 Test libvirt connection to remote Xen host
 
-- 
2.19.1.3.g30247aa5d201