Description of problem: Some systems are not longer using ssh-dss by default, which results in some issues like: Client side: "[lazarotti@mackoy-note git-test]$ git clone ssh://lazarotti@localhost:8001/gss-repo Cloning into 'gss-repo'... Unable to negotiate with 127.0.0.1: no matching host key type found. Their offer: ssh-dss fatal: Could not read from remote repository." Server side: 14:58:31,856 WARN [org.apache.sshd.server.session.ServerSession] (sshd-SshServer[847507d]-nio2-thread-2) Exception caught: java.lang.IllegalStateException: Unable to negotiate key exchange for server host key algorithms (client: ecdsa-sha2-nistp256-cert-v01,ecdsa-sha2-nistp384-cert-v01,ecdsa-sha2-nistp521-cert-v01,ssh-ed25519-cert-v01,ssh-rsa-cert-v01,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-rsa / server: ssh-dss) at org.apache.sshd.common.session.AbstractSession.negotiate(AbstractSession.java:1109) [sshd-core-0.12.0.jar:0.12.0] at org.apache.sshd.common.session.AbstractSession.doHandleMessage(AbstractSession.java:357) [sshd-core-0.12.0.jar:0.12.0] at org.apache.sshd.common.session.AbstractSession.handleMessage(AbstractSession.java:295) [sshd-core-0.12.0.jar:0.12.0] ... while trying to clone a git repo from Business Central. As mentioned by https://issues.jboss.org/browse/ENTESB-4427 as a longer term solution we should start considering moving away from ssh-dss since according to http://www.openssh.com/legacy.html it's considered insecure, thus deprecated: > OpenSSH 7.0 and greater similarly disables the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use. Version-Release number of selected component (if applicable): BRMS 6.2.0 How reproducible: Always Steps to Reproduce: 1. try to clone a project repository using standard Fedora 23. I know it is not supported for BRMS 6.2.0, but it is how RHEL will be work soon. Additional info: Also from ENTESB-4427: An immediate workaround is to alter the configuration of ssh client to accept that security configuration: ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o PreferredAuthentications=password -oHostKeyAlgorithms=+ssh-dss -l admin -p 8101 localhost or: Host localhost VerifyHostKeyDNS no StrictHostKeyChecking no HostKeyAlgorithms +ssh-dss UserKnownHostsFile /dev/null can be added to ~/.ssh/config for a global configuration.
master: https://github.com/uberfire/uberfire/commit/cec879f64
*** Bug 1311731 has been marked as a duplicate of this bug. ***
Verified with BRMS 6.3.0.ER2 on Fedora 23. Reproduced the described problem, applied global configuration via ~/.ssh/config and successfully cloned after that.
Team, What was actually verified here??? I'm testing with 6.3.0 GA and I get still get "no matching host key type found. Their offer: ssh-dss fatal: Could not read from remote repository." Alexandre's commit seems to add RSA support, but that does not appear to be in the product.
https://issues.jboss.org/browse/RHBRMS-243
Justin, SFU, see please the Jira above. The Bouncy Castle JCE must be installed in applicaiton server to make it work