Broken Git operations via SSH with ed25519 keys

[HannesWell]

Let's make sure issue is not already fixed in latest builds first.

• I verified I can reproduce this issue against latest Integration Build of Eclipse SDK

Steps to reproduce

From a fresh installation and clean workspace:

• In a clean Eclipse Platform/SDK produkt install Git Integration for Eclipse, for example from:
  • https://download.eclipse.org/egit/updates/
• Configure SSH in the preferences to use an id_ed25519 key
• Add a repository to the Git repositories view, for example an existing one that has a remote with SSH URL
• Fetch from the remote using an SSH URL
• The error message below appears and nothing is fetched or pushed.

In the latest Release of Eclipse and E/JGit everything works fine and I have already triaged it with different I-builds and the EGit nightly build that this isn't an issue in EGit and is introduced between
I20250914-1800 and I20250917-0740. The former works and the latter is broken.
I'll triage further trying to pin it down to one build.
And I also suspect that this is an issue introduced by a dependency update as I don't see relevant changes in the area of SSH actually.
But as this repo provides the SSH settings, I assume this to be the place where others start to search.

Here is some relevant log output

eclipse.buildId=4.38.0.I20250917-0740
java.version=21.0.6
java.vendor=Eclipse Adoptium
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_DE
Command-line arguments:  -os win32 -ws win32 -arch x86_64 -data file:/C:/Users/Hannes/Downloads/eclipse-platform-I20250917-0740-win32-x86_64/workspace/

org.eclipse.egit.ui
Error
Sun Sep 21 08:00:45 CEST 2025
git@github.com:HannesWell/eclipse.platform.releng.aggregator.git: Cannot log in at github.com:22
publickey: no keys to try

org.eclipse.core.runtime.CoreException: git@github.com:HannesWell/eclipse.platform.releng.aggregator.git: Cannot log in at github.com:22
publickey: no keys to try
	at org.eclipse.egit.ui.internal.fetch.FetchOperationUI.execute(FetchOperationUI.java:114)
	at org.eclipse.egit.ui.internal.fetch.FetchOperationUI$1.performJob(FetchOperationUI.java:137)
	at org.eclipse.egit.ui.internal.jobs.RepositoryJob.run(RepositoryJob.java:59)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: org.eclipse.jgit.api.errors.TransportException: git@github.com:HannesWell/eclipse.platform.releng.aggregator.git: Cannot log in at github.com:22
publickey: no keys to try
	at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:249)
	at org.eclipse.egit.core.op.FetchOperation.run(FetchOperation.java:134)
	at org.eclipse.egit.ui.internal.fetch.FetchOperationUI.execute(FetchOperationUI.java:111)
	... 3 more
Caused by: org.eclipse.jgit.errors.TransportException: git@github.com:HannesWell/eclipse.platform.releng.aggregator.git: Cannot log in at github.com:22
publickey: no keys to try
	at org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:181)
	at org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:100)
	at org.eclipse.jgit.transport.sshd.SshdSessionFactory.getSession(SshdSessionFactory.java:260)
	at org.eclipse.jgit.transport.sshd.SshdSessionFactory.getSession(SshdSessionFactory.java:1)
	at org.eclipse.jgit.transport.SshTransport.getSession(SshTransport.java:107)
	at org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.<init>(TransportGitSsh.java:285)
	at org.eclipse.jgit.transport.TransportGitSsh.openFetch(TransportGitSsh.java:152)
	at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:153)
	at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:105)
	at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1458)
	at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:238)
	... 5 more
Caused by: org.apache.sshd.common.SshException: No more authentication methods available
	at org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:141)
	at org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:56)
	at org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:35)
	at org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:110)
	at org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:96)
	at org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:171)
	... 15 more
Caused by: org.apache.sshd.common.SshException: No more authentication methods available
	at org.apache.sshd.client.session.ClientUserAuthService.tryNext(ClientUserAuthService.java:441)
	at org.apache.sshd.client.session.ClientUserAuthService.processUserAuth(ClientUserAuthService.java:375)
	at org.apache.sshd.client.session.ClientUserAuthService.process(ClientUserAuthService.java:270)
	at org.apache.sshd.common.session.helpers.CurrentService.process(CurrentService.java:109)
	at org.apache.sshd.common.session.helpers.AbstractSession.doHandleMessage(AbstractSession.java:634)
	at org.apache.sshd.common.session.helpers.AbstractSession.lambda$handleMessage$0(AbstractSession.java:555)
	at org.apache.sshd.common.util.threads.ThreadUtils.runAsInternal(ThreadUtils.java:68)
	at org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:554)
	at org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSession.java:1738)
	at org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(AbstractSession.java:515)
	at org.eclipse.jgit.internal.transport.sshd.JGitClientSession.messageReceived(JGitClientSession.java:223)
	at org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:76)
	at org.apache.sshd.common.io.nio2.Nio2Session.handleReadCycleCompletion(Nio2Session.java:409)
	at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:382)
	at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:377)
	at org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
	at org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
	at java.base/sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:129)
	at java.base/sun.nio.ch.Invoker$2.run(Invoker.java:221)
	at java.base/sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:113)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.lang.Thread.run(Thread.java:1583)

Tested under this environment:

• OS & version: Windows 10
• Eclipse IDE/Platform version (as shown in Help > About): I20250917-0740 and later

Community

• I understand reporting an issue to this OSS project does not mandate anyone to fix it. Other contributors may consider the issue, or not, at their own convenience. The most efficient way to get it fixed is that I fix it myself and contribute it back as a good quality patch to the project.

[tomaswolf]

What versions of EGit, JGit, and of the Bouncy Castle bundles do you have in that IDE?

[merks]

My wild guess would be that a combination of 1.81.0 and 1.82.0 is used because the Platform uses a smaller subset of Bouncycastle and has recently updated.

[merks]

For me, the staging version to the committer's product:

does contain mixed versions

I have these keys

And this GitHub

Cloning use SSH worked for me with this.

[HannesWell]

is introduced between I20250914-1800 and I20250917-0740.

I have no further bisected the builds in between and the problem occurs first with I20250917-0740, which has quite a number of changes, including a bouncy-castle update (which is in an area that seems related to the problem):
https://download.eclipse.org/eclipse/downloads/drops4/I20250917-0740/gitLog.php

Cloning use SSH worked for me with this.

I cannot see what kind of key this is? With an RSA key everything works fine for me too. Only ed25519 fails.

What versions of EGit, JGit, and of the Bouncy Castle bundles do you have in that IDE?

I used the latest EGit/JGit release in both, my eclipse-platform installation with I20250917-0740 and I20250917-0250:

With I20250917-0250 the bouncycastle bundles are:

and for I20250917-0740 the bouncycastle bundles are:

My wild guess would be that a combination of 1.81.0 and 1.82.0 is used because the Platform uses a smaller subset of Bouncycastle and has recently updated.

With the lists above, I assume the same.
Maybe it doesn't work for me, but for you, because I installed EGit manually afterwards and you had it preinstalled and now the OSGi wiring is different.

[HannesWell]

Maybe it doesn't work for me, but for you, because I installed EGit manually afterwards and you had it preinstalled and now the OSGi wiring is different.

Starting with -clean didn't improved the situation :/

[merks]

You could maybe verify that theory by using Navigate -> Open Setup -> Installation, pasting this in the installation

<?xml version="1.0" encoding="UTF-8"?>
<setup.p2:P2Task
    xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI"
    xmlns:setup.p2="http://www.eclipse.org/oomph/setup/p2/1.0">
  <requirement
      name="bcpg"
      versionRange="[1.82.0,2.0.0)"/>
  <requirement
      name="bcpkix"
      versionRange="[1.82.0,2.0.0)"/>
  <requirement
      name="bcprov"
      versionRange="[1.82.0,2.0.0)"/>
  <requirement
      name="bcutil"
      versionRange="[1.82.0,2.0.0)"/>
  <repository
      url="https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/nightly/latest"/>
</setup.p2:P2Task>

and then using Perform Setup Tasks to run the p2 task. This should ensure that 1.82 versions of everything are installed. Maybe it will work again, in which case we just need EGit/JGit to update to the new versions.

[laeubi]

If you start Eclipse with -console (or open the OSGi host console in the UI) then you can use

• ss bc (=show status of all bundles containing 'bc')
• wires <id of a bundle from previous command> (see http://equinox.eclipseprojects.io/commands/wires.html)

This will give you results of the wiring and is probably easier to compare than some assumptions about what might happen. Just because an older bundle is there, it does not mean it gets selected by OSGi if there is no good reason, OSGi will always use latest!

[HannesWell]

This should ensure that 1.82 versions of everything are installed. Maybe it will work again, in which case we just need EGit/JGit to update to the new versions.

Bingo. With all bouncycastle bundles of version 1.82 it works again! Thanks for the suggestion and the setup snippet.

@tomaswolf if you could update EGit/JGit to the new bouncycastle version then I'd be happy to consume the Egit/JGit nightly build (I'm doing this already anyways).

[tomaswolf]

Why did you end up with that mixture? I'd suggest that Platform include bcpkix 1.82, too. Probably bcpkix 1.81 got pulled in because it wasn't present but needed for some package in JGit or in Apache MINA SSHD (bundle sshd-osgi), and then bcpkix 1.81 pulled in the rest of the 1.81 BC bundles. If pxpkix 1.82 had been there to start with, none of this would have happened.

Of course we can bump the lower bound for BC in EGit and in JGit. But note that Apache MINA SSHD (bundle sshd-osgi) also still has the lower bound of 1.81. It would need to be bumped there, too.

[laeubi]

Why did you end up with that mixture? I'd suggest that Platform include bcpkix 1.82, too.

The question should more be: Why is it causing an issue? This usually indicates a problem in the generated manifests (e.g. incorrect version ranges on import, missing use clauses on exports) and should be reported/fixed at BouncyCastle then, in wich case P2 would have pulled in the required items automatically and OSGi would wire it correctly.

So bumping the lower version, is usually not the correct way of fixing that, it only hides the problem!

[HannesWell]

Why did you end up with that mixture? I'd suggest that Platform include bcpkix 1.82, too.

The question should more be: Why is it causing an issue? This usually indicates a problem in the generated manifests (e.g. incorrect version ranges on import, missing use clauses on exports) and should be reported/fixed at BouncyCastle then, in wich case P2 would have pulled in the required items automatically and OSGi would wire it correctly.

I agree with that assessment, but looking at the current Manifest.MF files of bcpg or bcpkix in version 1.81 and 1.82, I see that that it's already done as suggested. All bouncy-castle packages are imported with a tight version range already excluding the next minor version and all exports have uses directives.

Why did you end up with that mixture? I'd suggest that Platform include bcpkix 1.82, too. Probably bcpkix 1.81 got pulled in because it wasn't present but needed for some package in JGit or in Apache MINA SSHD (bundle sshd-osgi), and then bcpkix 1.81 pulled in the rest of the 1.81 BC bundles. If pxpkix 1.82 had been there to start with, none of this would have happened.

Yes that's probably the reason.

Of course we can bump the lower bound for BC in EGit and in JGit. But note that Apache MINA SSHD (bundle sshd-osgi) also still has the lower bound of 1.81. It would need to be bumped there, too.

As Christoph outlined, ideally the mixture would just work. But I cannot tell what exactly is causing the problem.

[laeubi]

I agree with that assessment, but looking at the current Manifest.MF files of bcpg or bcpkix in version 1.81 and 1.82, I see that that it's already done as suggested

That's why I also suggested to look at the actual wiring (instead of staring at the static metadata), this sometime give interesting insights and is the only thing that counts at runtime.

[merks]

Why did you end up with that mixture? I'd suggest that Platform include bcpkix 1.82, too. Probably bcpkix 1.81 got pulled in because it wasn't present but needed for some package in JGit or in Apache MINA SSHD (bundle sshd-osgi), and then bcpkix 1.81 pulled in the rest of the 1.81 BC bundles. If pxpkix 1.82 had been there to start with, none of this would have happened.

Of course we can bump the lower bound for BC in EGit and in JGit. But note that Apache MINA SSHD (bundle sshd-osgi) also still has the lower bound of 1.81. It would need to be bumped there, too.

Here is why there is a mixture:

There is one bundle bcpkix that is only required by JGit/EGit and not by the Platform. So when the Platform updates its versions, p2 will generally want to installed the newest versions of every which for bcpkix remains 1.81.0 until JGit/EGit updates to it and provides that in the p2 repository.

Given the platform doesn't use this bundle, it doesn't make so much sense for it to add a dependency for it.

Here's what we see aggregated in SimRel. The ranges in BouncyCastle appear fine. Generally all the ranges appear fine (in p2, which doesn't provide uses information). But still there is a combination of versions because nothing provides bcpkix 1.82.0 and EGit really needs bcpkix:

So the easiest solution (however non-prefect that solution may be) is for EGit to update to 1.82.0 as soon as possible, ideally with a new SimRel contribution because the staging products take forever to start, so likely there is a very hard wiring problem to solve with this being a leading suspect.

[laeubi]

because the staging products take forever to start, so likely there is a very hard wiring problem to solve with this being a leading suspect

I'm working already on this but have not finished it yet here as there is still some little case I'd like to be covered:

• Improve substitution package handling and filter uses locally eclipse-equinox/equinox#1124

In any case it would be great to export the wiring database:

1. Open the OSGi Host Console from the console view
2. exportFrameworkState <file to export> false
3. Share the file here or elsewhere so I can add it as a testcase and further analyze it!