Red Hat Bugzilla – Bug 1007133
PRD35 - [RFE][host-deploy] support more ciphers for ssh - upgrade apache-sshd to 0.11.0
Last modified: 2016-02-10 14:33:41 EST
Description of problem: SSH communication error while adding a RHEL host to RHEV-M. When RHEL host is customized/configured to use non-default cipher list for SSH, it cannot be added to RHEV-M.
The engine.log contains below error
2013-08-23 09:17:53,387 ERROR [org.ovirt.engine.core.utils.hostinstall.VdsInstallerSSH] (http-/0.0.0.0:8443-4) Could not connect to server 22.214.171.124: java.io.IOException: SSH session closed during connection '126.96.36.199:22'
The /var/log/messages on RHEL host contains below error
Aug 28 08:53:07 celerity-hst3 sshd: fatal: no matching cipher found:
This prevents customers from using far more secure CTR ciphers, as we use default CBC ciphers.
Version-Release number of selected component (if applicable):
Apache sshd-core.version : 0.7.0
Edit sshd config file on RHEL host to add custom ciphers, then try adding it to RHEV-M. It will fail with SSH error.
Steps to Reproduce:
1.Edit /etc/ssh/sshd_config file on RHEL host and add below line
2.# service sshd restart
3. Try to add RHEL host to RHEV-M
Not able to add host due to SSH communication error
Host should be added into RHEV-M
We still use sshd-core version 0.7.0, although Apache has already added the support of Non-CBC ciphers in version 0.8.0 due to security vulnerability (chosen-plaintext attacks) in CBC ciphers used.
Due to older version we restrict cutomers from using Non-CBC ciphers and make there RHEL hosts vulnerable to security attacks.
Note : Even RHEV-M 3.2 uses the same version 0.7.0
Due to older version , SSHClient used in RHEV-M uses only CBC ciphers.
Version used in rhevm backend
Ciphers used in Apache sshd-core 0.7.0
Ciphers used in Apache sshd-core 0.8.0
//Newly added after a security bug fix
Good example of what we just discussed.
Current state is:
PACKAGE POM FC19 EL6
apache-mina 2.0.1 2.0.4-6 N/A
apache-sshd 0.7.0 0.7.0-3 N/A
So even fedora 19 does not support this mode.
We can provide our own jars for EL6 to meet functionality requirement as it is not packages in EL6 (advantage?).
Then downgrade this and lose functionality in fedora as we want to use system jars. Or, depend on >=0.8.0 and force someone to provide correct rpms (us?).
Customer wants to know, if for the temporary workaround can they use default SSH cipher settings to register host, later change the SSH cipher settings back to what they prefer.
Will it break RHEV environment?
Apart from Install/Upgrade, for what other functions/operations do we need SSH communication between [ manager <==> host ] in RHEV environment?
(In reply to Aval from comment #3)
> Customer wants to know, if for the temporary workaround can they use default
> SSH cipher settings to register host, later change the SSH cipher settings
> back to what they prefer.
> Will it break RHEV environment?
It will not break rhev-3.2.
> Apart from Install/Upgrade, for what other functions/operations do we need
> SSH communication between [ manager <==> host ] in RHEV environment?
In rhev-3.3 a new feature is using ssh which is software fencing, so software fencing will not be available.
Apart from that there is the log-collector which relays on ssh, it currently uses the ssh command.
Arthur Berezin 2013-09-23 09:34:44 EDT
> Target Release: 3.3.0 → 3.4.0
> Flags: rhevm-3.3.0? → rhevm-3.4.0?
As this is going to 3.4.0 now, it is not important so much for now.
Not a solution, but allows clean site specific workaround.
Author: Alon Bar-Lev <email@example.com>
Date: Wed Sep 25 22:56:17 2013 +0300
packaging: support modifying java module path
if a customer need to have more recent version of module, he currently
have no way to apply except of replacing pre-installed files.
this change allows customer to add his own module path to search path to
shadow product modules.
Signed-off-by: Alon Bar-Lev <firstname.lastname@example.org>
In this case, this will enable customer to shadow product mina-core.jar and sshd-core.jar with newer versions.
Moving to rhevm-future,
The mechanism to override the product's jboss modules was added to 3.3,
Once a newer/stable apache-sshd version will be available this issue will be solvable within the product itself.
Added improvement keyword.
Moved back to rhevm-future
apache-sshd-0.11.0 is out, finally all issues are resolved so we can use it.
Doubts about aes192-ctr, a mail sent to rhev-devel list.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.