[
https://issues.apache.org/jira/browse/SSHD-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010455#comment-15010455
]
Alon Bar-Lev commented on SSHD-589:
-----------------------------------
Please help me out here, I do not fully understand.
1. If I add explicit reference to a specific jvm and that jvm adds support for
DH 4096 the unit test will fails, I already sent you that there are pending
requests for this. We know we have exception if it is unsupported, we do not
check the jvm we check our code. We know that during initialize we will get
exception if key is unsupported, this is a constant. The question is if we
detect this exception or not.
2. This only suggests that best to use synthetic provider, so we do not care
which environment we are running on. Again, we know how various environments
behave and we check our reaction to each behaviour. This is why
mocking/synthetic are used in unit tests, to be able to detach from the
environment while checking our behaviour.
3. I already wrote you that I am not a master in ssh, we are referencing
dhgex256, what DH size is required for this algorithm to work? I can lower the
check for 3072 if this helps. If a range of bits is required, I guess the
interface of the algorithms should be modified to report minimum and maximum,
but I do not see there is such implementation for any other algorithm in code,
this is probably a separate enhancement.
> [regression][kex] dhgex256 is disabled in 1.x if native JCE is being used
> -------------------------------------------------------------------------
>
> 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
> Priority: Minor
> Attachments:
> 0001-SSHD-589-Enable-dhgex256-if-4096-DH-is-supported.patch,
> 0001-SSHD-589-Logging-improvements.patch,
> 1000-SSHD-589-Enable-dhgex256-if-4096-DH-is-supported.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)
