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 128.165.232.103: java.io.IOException: SSH session closed during connection '128.165.232.103:22' The /var/log/messages on RHEL host contains below error Aug 28 08:53:07 celerity-hst3 sshd[28499]: fatal: no matching cipher found: client aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc server aes128-ctr,aes192-ctr,aes256-ctr This prevents customers from using far more secure CTR ciphers, as we use default CBC ciphers. Version-Release number of selected component (if applicable): rhevm-3.1.0-55.el6ev.noarch Apache sshd-core.version : 0.7.0 How reproducible: 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 Ciphers aes128-ctr,aes192-ctr,aes256-ctr 2.# service sshd restart 3. Try to add RHEL host to RHEV-M Actual results: Not able to add host due to SSH communication error Expected results: Host should be added into RHEV-M Additional info: 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 == pom.xml: <sshd-core.version>0.7.0</sshd-core.version> == Ciphers used in Apache sshd-core 0.7.0 == avail.add(new AES128CBC.Factory()); avail.add(new TripleDESCBC.Factory()); avail.add(new BlowfishCBC.Factory()); avail.add(new AES192CBC.Factory()); avail.add(new AES256CBC.Factory()); == Ciphers used in Apache sshd-core 0.8.0 == //Newly added after a security bug fix avail.add(new AES128CTR.Factory()); avail.add(new AES256CTR.Factory()); avail.add(new ARCFOUR128.Factory()); avail.add(new ARCFOUR256.Factory()); avail.add(new AES128CBC.Factory()); avail.add(new TripleDESCBC.Factory()); avail.add(new BlowfishCBC.Factory()); avail.add(new AES192CBC.Factory()); avail.add(new AES256CBC.Factory()); ==
Itamar, 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. commit 691442bea852ea4ebac95f59ac8e3c767fe543ee Author: Alon Bar-Lev <alonbl> 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. Change-Id: Ibda53f67fa801cf4eb00b11483e9a6ab712d4d74 Signed-off-by: Alon Bar-Lev <alonbl> --- 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.
ok, ovirt-3.5-pre
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. https://rhn.redhat.com/errata/RHSA-2015-0158.html