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

Buzkie
  • 195
  • 4
  • 11
  • 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 03:19

1 Answers1

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

Community
  • 1
dave_thompson_085
  • 3,262
  • 1
  • 16
  • 16
  • 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 00: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 03:18