|
 |
c1a9fa |
From 3f7f730ac9cbf38267839ffcebd6b6fd721123c5 Mon Sep 17 00:00:00 2001
|
|
|
c1a9fa |
From: Laszlo Ersek <lersek@redhat.com>
|
|
|
c1a9fa |
Date: Mon, 11 Jul 2022 09:01:57 +0200
|
|
|
c1a9fa |
Subject: [PATCH] input-xen: replace "enable LEGACY crypto" advice with
|
|
|
c1a9fa |
targeted ssh options
|
|
|
c1a9fa |
|
|
|
c1a9fa |
- "KexAlgorithms": the Fedora 35 ssh binary, using the DEFAULT
|
|
|
c1a9fa |
crypto-policy, cannot log in to RHEL5 sshd without relaxing
|
|
|
c1a9fa |
"KexAlgorithms". The server offers three algorithms:
|
|
|
c1a9fa |
"diffie-hellman-group-exchange-sha1", "diffie-hellman-group14-sha1",
|
|
|
c1a9fa |
"diffie-hellman-group1-sha1"; and according to RFC 9142,
|
|
|
c1a9fa |
"diffie-hellman-group14-sha1" is the least deprecated from those. (The
|
|
|
c1a9fa |
RFC marks it as MAY be implemented, and marks the other two as SHOULD
|
|
|
c1a9fa |
NOT be implemented.) Recommend "diffie-hellman-group14-sha1".
|
|
|
c1a9fa |
|
|
|
c1a9fa |
- "MACs": the Fedora 35 ssh binary, using the FUTURE crypto-policy, cannot
|
|
|
c1a9fa |
log in to RHEL5 sshd without relaxing "MACs". The server offers
|
|
|
c1a9fa |
"hmac-md5", "hmac-sha1", "hmac-ripemd160", "hmac-ripemd160@openssh.com",
|
|
|
c1a9fa |
"hmac-sha1-96", "hmac-md5-96". After eliminating the MD5-based algos
|
|
|
c1a9fa |
(MD5 is considered completely broken), and the one based on truncated
|
|
|
c1a9fa |
SHA1, we're left with "hmac-sha1", "hmac-ripemd160", and
|
|
|
c1a9fa |
"hmac-ripemd160@openssh.com". RIPEMD-160 is generally trusted, but it is
|
|
|
c1a9fa |
compiled out of the Fedora 35 "ssh" client binary. Therefore only
|
|
|
c1a9fa |
"hmac-sha1" remains.
|
|
|
c1a9fa |
|
|
|
c1a9fa |
- "HostKeyAlgorithms", "PubkeyAcceptedAlgorithms": these options control
|
|
|
c1a9fa |
the usage of public key algorithms, for authenticating the server to the
|
|
|
c1a9fa |
client, and vice versa, respectively. RHEL5 sshd only supports "ssh-rsa"
|
|
|
c1a9fa |
and "ssh-dss", and from those, "ssh-rsa" is more commonly used (for
|
|
|
c1a9fa |
example, "ssh-keygen" defaults to creating "ssh-rsa" keys). Recommend
|
|
|
c1a9fa |
"ssh-rsa".
|
|
|
c1a9fa |
|
|
|
c1a9fa |
- "PubkeyAcceptedKeyTypes": this is the old ("legacy") name for
|
|
|
c1a9fa |
"PubkeyAcceptedAlgorithms". As of this writing, the latest upstream
|
|
|
c1a9fa |
release of libssh (also packaged in Fedora 35 -- libssh-0.9.6-1.fc35)
|
|
|
c1a9fa |
does not recognize the new "PubkeyAcceptedAlgorithms" option name, only
|
|
|
c1a9fa |
the original "PubkeyAcceptedKeyTypes". openssh-8.7p1-3.fc35 recognizes
|
|
|
c1a9fa |
both option variants. Include "PubkeyAcceptedKeyTypes" in the
|
|
|
c1a9fa |
recommendation along with "PubkeyAcceptedAlgorithms", for backward and
|
|
|
c1a9fa |
forward compatbility.
|
|
|
c1a9fa |
|
|
|
c1a9fa |
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2062360
|
|
|
c1a9fa |
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
|
|
|
c1a9fa |
Message-Id: <20220711070157.5399-3-lersek@redhat.com>
|
|
|
c1a9fa |
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
|
|
|
c1a9fa |
(cherry picked from commit af4a0454cdd21bb5e86f2dbfaa153e83afca3988)
|
|
|
c1a9fa |
---
|
|
|
c1a9fa |
docs/virt-v2v-input-xen.pod | 20 +++++++++++++++-----
|
|
|
c1a9fa |
1 file changed, 15 insertions(+), 5 deletions(-)
|
|
|
c1a9fa |
|
|
|
c1a9fa |
diff --git a/docs/virt-v2v-input-xen.pod b/docs/virt-v2v-input-xen.pod
|
|
|
c1a9fa |
index 80ad94f7..1775fc31 100644
|
|
|
c1a9fa |
--- a/docs/virt-v2v-input-xen.pod
|
|
|
c1a9fa |
+++ b/docs/virt-v2v-input-xen.pod
|
|
|
c1a9fa |
@@ -37,12 +37,22 @@ option is incomplete. Some operations remain that still require the
|
|
|
c1a9fa |
user to enter the password manually. Therefore ssh-agent is recommended
|
|
|
c1a9fa |
over the I<-ip> option. See L<https://bugzilla.redhat.com/1854275>.
|
|
|
c1a9fa |
|
|
|
c1a9fa |
-With some modern ssh implementations, legacy crypto policies required
|
|
|
c1a9fa |
-to interoperate with RHEL 5 sshd are disabled. To enable them you may
|
|
|
c1a9fa |
-need to run this command on the conversion server (ie. ssh client),
|
|
|
c1a9fa |
-but read L<update-crypto-policies(8)> first:
|
|
|
c1a9fa |
+With some modern ssh implementations, legacy crypto algorithms required
|
|
|
c1a9fa |
+to interoperate with RHEL 5 sshd are disabled. To enable them, you may
|
|
|
c1a9fa |
+need to add the following C<Host> stanza to your F<~/.ssh/config>:
|
|
|
c1a9fa |
|
|
|
c1a9fa |
- # update-crypto-policies --set LEGACY
|
|
|
c1a9fa |
+ Host xen.example.com
|
|
|
c1a9fa |
+ KexAlgorithms +diffie-hellman-group14-sha1
|
|
|
c1a9fa |
+ MACs +hmac-sha1
|
|
|
c1a9fa |
+ HostKeyAlgorithms +ssh-rsa
|
|
|
c1a9fa |
+ PubkeyAcceptedKeyTypes +ssh-rsa
|
|
|
c1a9fa |
+ PubkeyAcceptedAlgorithms +ssh-rsa
|
|
|
c1a9fa |
+
|
|
|
c1a9fa |
+(C<PubkeyAcceptedKeyTypes> and C<PubkeyAcceptedAlgorithms> have
|
|
|
c1a9fa |
+identical meaning; the former is the old option name, the latter is the
|
|
|
c1a9fa |
+new one. Virt-v2v uses both C<libssh> and C<ssh> when converting a guest
|
|
|
c1a9fa |
+from Xen, and on some operating systems, C<libssh> and C<ssh> may not
|
|
|
c1a9fa |
+both accept the same option variant.)
|
|
|
c1a9fa |
|
|
|
c1a9fa |
=head2 Test libvirt connection to remote Xen host
|
|
|
c1a9fa |
|