Replies: 1 comment
-
Sorry, I'm not familiar with the internals of JSch how is it looking for Ed25519 in the provider? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
When using the Bouncy Castle FIPS 2.1.1 provider with JSch (mwiede fork) on Java 8, ED25519 keys cannot be used successfully. Other algorithms work as expected, but attempts with ED25519 result in failures.
Steps to Reproduce:
Configure Java 8 with the BC FIPS 2.1.1 provider.
Use JSch (mwiede fork) to connect to an SSH server with an ED25519 key.
Attempt authentication.
Expected Behavior:
Authentication with ED25519 keys should succeed when using the BC FIPS provider.
Actual Behavior:
Authentication fails with ED25519 keys. Other algorithms (e.g., RSA, ECDSA) succeed.
Environment:
Java version: 1.8.x
Bouncy Castle FIPS provider: 2.1.1
JSch (mwiede fork)
OS: Mac OS, Windows
This issue seems specific to the interaction between JSch (mwiede fork) and the BC FIPS provider when ED25519 is used. Non-FIPS providers and other algorithms work correctly.
Here is the log that I am getting:
And here is the code for the app that I am using to test: https://github.com/jogevego/vm-connector
Beta Was this translation helpful? Give feedback.
All reactions