[
https://issues.apache.org/jira/browse/SSHD-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15008313#comment-15008313
]
Goldstein Lyor commented on SSHD-589:
-------------------------------------
I would also be interested in understanding why in 0.14 it works. Since you can
reproduce the problem consistently (I do not have the time or resources to do
so) I am afraid it falls on you (if you are willing) to try. After having
looked at the KEX difference between 0.14 and 1.0 I think I have a lead that
you can try. In 0.14 the "diffie-hellman-group-exchange-sha256" was **always**
included, so even if you don't have EC, your client would be able to do KEX
given the server's capabilities that are listed. In version 1.0 this type of
KEX depends on _Bouncycastle_ in order to avoid the {quote}Prime size must be
multiple of 64, and can only range from 512 to 2048 (inclusive){quote} issue.
We did this because it is safer this way and there are no surprises (imagine
having **sporadic** failures based on whether the other side happened to choose
a key > 2048 bits...).
Just for testing, for the 1.1 code, go to the _BuiltinDHFactories_ and change
the _isSupported_ method return value of _dhgex256_ to _true_. Then re-compile
and test. If it succeeds (which I suspect it will), let me know, but we need to
find a way to avoid **a-priori** using "diffie-hellman-group-exchange-sha256"
if {quote}Prime size must be multiple of 64, and can only range from 512 to
2048 (inclusive){quote}
> [regression][kex] client 1.x cannot connect to a machine 0.14 could
> -------------------------------------------------------------------
>
> Key: SSHD-589
> URL: https://issues.apache.org/jira/browse/SSHD-589
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 1.0.0, 1.1.0
> Environment: Fedora
> $ java -version
> openjdk version "1.8.0_60"
> OpenJDK Runtime Environment (build 1.8.0_60-b27)
> OpenJDK 64-Bit Server VM (build 25.60-b23, mixed mode)
> Gentoo
> $ java -version
> openjdk version "1.8.0_60"
> OpenJDK Runtime Environment (IcedTea 3.0.0pre06+ra9817b9f8a21) (Gentoo
> icedtea-3.0.0_pre06)
> OpenJDK 64-Bit Server VM (build 25.60-b23, mixed mode)
> Oracle
> NOTE1: Disable SunEC provider at jre/lib/security/java.security to reproduce.
> NOTE2: Install UnlimitedJCEPolicyJDK8
> $ java -version
> java version "1.8.0_65"
> Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)
> $ sshd -V
> OpenSSH_6.9p1, OpenSSL 1.0.1k-fips 8 Jan 2015
> Reproduce server: dev.gentoo.org (Kex only)
> Reporter: Alon Bar-Lev
> Attachments: 0001-SSHD-589-Logging-improvements.patch,
> test1-0.14.log, test1-master.log, test1.tar.gz
>
>
> Using:
> 1. Same JVM to run test of 1.x and 0.x
> 2. The SunEC provider is not available.
> 3. BouncyCastle is not used.
> 4. The same Fedora-22 remote is accessed.
> Using sshd-core-0.14 works, using sshd-core-1.0.1(master, and any 1.x)
> produces:
> java.lang.IllegalStateException: Unable to negotiate key exchange for kex
> algorithms (client:
> diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 / server:
> [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1)
> at
> org.apache.sshd.common.session.AbstractSession.negotiate(AbstractSession.java:1334)
> at
> org.apache.sshd.common.session.AbstractSession.handleKexInit(AbstractSession.java:478)
> at
> org.apache.sshd.common.session.AbstractSession.doHandleMessage(AbstractSession.java:412)
> at
> org.apache.sshd.common.session.AbstractSession.handleMessage(AbstractSession.java:361)
> Per Lyor request, added some more debug information into master.
> Attached:
> 1. Full test environment (test1.tar.gz) a directory per version, test using:
> JAVA_OPTS="-Djava.util.logging.config.file=./logging.properties"
> ./ssh-test.sh --host=XXXX --password=XXXX --command="echo hello"
> 2. Full debug log of 0.14 and master.
> 3. Diff of logging.
> This is a behaviour change in 1.x, so far we have failed to nail it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
