[jira] [Commented] (SSHD-589) [regression][kex] dhgex256 is disabled in 1.x if native JCE is being used

["Goldstein Lyor (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SSHD-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15008362#comment-15008362 ] 

Goldstein Lyor commented on SSHD-589:
-------------------------------------

Sorry, can't - like you said "OpenJDK does support DH > 2048" but SunJCE does not. We cannot start making decisions based on specific JDKs or versions thereof. We have to use the lowest common denominator. Specifically for you, you can set up your client any way you like:
{code:java}
SshClient client = SshClient.setupDefaultClient();   // this will exclude DH > 2048 in your case unless you have _Bouncycastle_ (which is the provider we chose to use since it is the most popular)
List<NamedFactory<KeyExchange>> kex = client.getKeyExchangeFactories();
if (...go over the list and not found  "diffie-hellman-group-exchange-sha256") {
   kex.add(ClientBuilder.DH2KEX.transform(BuiltinDhFactories.dhgex256));
}
{code}
Of course you are taking the risk that if you try to run you code on a JVM that does not support DH > 2048 you will have *sporadic* failures - depending on whether the server chose such a key. If you can suggest a clever, *efficient* and *portable* way to automatically detect if DH > 2048 is supported then we can incorporate it into the generic code.

> [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-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: curve25519-sha256@libssh.org,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)