0

I'm attempting to use my applications SFTP client test connection to connect to the MF but I'm getting the error:

Test of SFTP user alias GLDFundingEngine_User failed. Details: Session.connect: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 2048 (inclusive)

This is a built in client so I don't have much control over it. I tested the both keys and they should be good:

ssh-keygen -lf intserv.rsa.pub
2048

ssh-keygen -lf GLDFundingEngine_XXXXXXXXXXXXXXXXXXXX_22_rsa.pub
1024

Is there something else this error could be pointing to? Searching stack exchange just points to different SSH libraries which I don't have the ability to change.

Thanks

  • Note this solution applies directly to webmethods 9.5 and above. Modify the Preferred Key Exchange Algorithm to one other than the default DH Algorithm. – Buzkie Nov 12 '16 at 3:19
3

The problem is definitely not your key; it's most likely the server's Diffie-Hellman parameters -- or possibly their DSA key, but not too many people use DSA keys for SSH, especially since OpenSSH deprecated them recently. It might be worth taking a network trace to see exactly when the error is occurring: on initial negotiation of e.g. group14; or DHGEXgroup and its params; or DH(GEX)reply containing a DSA signature and that signature.

If you're using Sun/Oracle Java before version 8, it can't handle DH (or DSA) sizes above 1024, but DH size 1024 is now considered vulnerable so many servers use 2048. See https://weakdh.org and http://www.keylength.org and/or the many Qs mostly on security.SX and crypto.SX about Logjam. In this case you have two choices: upgrade to Java 8, where DH (and DSA) 2048 works; or if the server supports ECDH and the SSH library you are using and can't change also does but you're using Java 6 (or lower?) which doesn't, add the provider from http://www.bouncycastle.org which does support ECDH, which generally is preferred over classic-DH and thus avoids the problem.

If you're using IBM Java, as I wildly speculate from the possibility MF -> mainframe -> IBM mainframe -> IBM shop, this answer doesn't apply directly. IBM Java uses IBM cryptoproviders which are different from the Sun/Oracle cryptoproviders in Sun/Oracle Java. However, if you check their documentation for DH parameter sizes and possibly DSA parameter sizes, there might be something similar.

If it isn't DH, then definitely look at a network trace, and if you can't figure it out, add the relevant parts to your question.

Crossdupe of
https://stackoverflow.com/questions/6851461/java-why-does-ssl-handshake-give-could-not-generate-dh-keypair-exception
https://stackoverflow.com/questions/10687200/java-7-and-could-not-generate-dh-keypair
https://stackoverflow.com/questions/21442547/java-ssl-dh-keypair-generation-prime-size-error
https://stackoverflow.com/questions/33088458/how-to-workaround-java-6-ssl-error

  • This is going from my JVM to an IBM MF. I believe the error is a message we are getting back from the MF. – Buzkie Jun 24 '16 at 14:27
  • @Buzkie The error is not itself a message; java.security.InvalidAlgorithmParameterException is an exception that occurs within your JVM (and more specifically within a cryptoprovider within your JVM). It is caused by parameters IN a handshake message from the server, which is why I suggest(ed) looking at a trace of those handshake messages, if updating your Java doesn't fix it. – dave_thompson_085 Jun 25 '16 at 0:00
  • This is deffinitely the answer. I changed the Preferred Key Exchange Algorithm in the sftp setup and it worked – Buzkie Nov 12 '16 at 3:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.