[v2v PATCH 0/2] input-xen: SSH authentication documentation improvements
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@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@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@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@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@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
On Mon, Jul 11, 2022 at 09:01:57AM +0200, Laszlo Ersek wrote:
- "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@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@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@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
For the series: Reviewed-by: Richard W.M. Jones <rjones@redhat.com> Thanks, Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
On 07/11/22 15:05, Richard W.M. Jones wrote:
On Mon, Jul 11, 2022 at 09:01:57AM +0200, Laszlo Ersek wrote:
- "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@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@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@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
For the series:
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Commit range 4368b94ee172..af4a0454cdd2. Thanks! Laszlo
participants (2)
-
Laszlo Ersek -
Richard W.M. Jones