I'm working for Karaf and Camel fix that would allow me to use ssh-ed25519 for server key.
EdDSA is supported via net.i2p.crypto/eddsa library, but its availability is checked in a way that is not correct (and not only in OSGi environment).
It's is also problematic for BouncyCastleSecurityProviderRegistrar, but actually for all methods that use org.apache.sshd.common.util.threads.ThreadUtils#resolveDefaultClassLoader(java.lang.Class<?>).
resolveDefaultClassLoader() method result is a classloader which is checked for availability of e.g., "net.i2p.crypto.eddsa.EdDSAKey" class, but the check result is cached statically. The problem is that if TCCL is used (which is generally not defined in OSGi) it may be a false negative.
More precisely - if in Karaf, I start Karaf's own sshd server with a TCCL that sees net.i2p.crypto.eddsa package, I can use EdDSA algorithm.
If I add camel-ssh usage, it may have own TCCL (depending on how Camel is started - e.g., through OSGi blueprint) - the first one who calls org.apache.sshd.common.util.security.eddsa.EdDSASecurityProviderRegistrar#isSupported() wins.
I'll work on a way to check more classloaders in search for given provider/registrar and send a PR soon.