Issue Summary

When running Bitbucket on Oracle Java 17, SSH operations are not possible with certain key types, including RSA and ED25519 (Others have not been tested)

This appears to be caused by a bug in the Oracle JDK.

When starting up Bitbucket on Java 17, several of the standard keys are missing from the Available list.

2023-08-04 09:23:19,782 DEBUG [spring-startup] c.a.b.i.s.s.DefaultNamedFactoryFilter Available SSH KEY_EXCHANGE: [ecdh-sha2-nistp521, ecdh-sha2-nistp384, ecdh-sha2-nistp256, diffie-hellman-group-exchange-sha256, diffie-hellman-group18-sha512, diffie-hellman-group17-sha512, diffie-hellman-group16-sha512, diffie-hellman-group15-sha512, diffie-hellman-group14-sha256]

Compared to a startup with Java 11:

2023-08-04 09:40:03,360 DEBUG [spring-startup] c.a.b.i.s.s.DefaultNamedFactoryFilter Available SSH KEY_EXCHANGE: [curve25519-sha256, curve25519-sha256@libssh.org, curve448-sha512, ecdh-sha2-nistp521, ecdh-sha2-nistp384, ecdh-sha2-nistp256, diffie-hellman-group-exchange-sha256, diffie-hellman-group18-sha512, diffie-hellman-group17-sha512, diffie-hellman-group16-sha512, diffie-hellman-group15-sha512, diffie-hellman-group14-sha256]
2023-08-04 09:40:03,361 DEBUG [spring-startup] c.a.b.i.s.s.DefaultNamedFactoryFilter Available SSH MAC: [hmac-sha2-256-etm@openssh.com, hmac-sha2-512-etm@openssh.com, hmac-sha1-etm@openssh.com, hmac-sha2-256, hmac-sha2-512, hmac-sha1]

When Bitbucket is determining which keys are available for use, a call is made to verify the bouncy castle Jar file (bcprov-jdk15on-1.70.jar), which fails with a java.lang.IllegalStateException: zip file closed error, which is the same error that's observed in the oracle bug ticket.

This is reproducible on Data Center: yes.

Steps to Reproduce

1. On a linux server running Oracle Java 17.0.8, try to clone a repo.

Expected Results

The repo is cloned

Actual Results

Cloning a repo fails with the below error. 

fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
 

Workaround

Either use an OpenJDK version of Java 17 instead of Oracle, or downgrade to Oracle Java 11. OpenJDK versions are not affected because unlike Oracle, they don't require third party cryptographic provider's JAR's to be signed by a known certificate. 

Another workaround that has not been explored yet, could be seeing if it's possible to disable the check (via a property perhaps) to verify the JAR files in the Oracle JDK.