This is a rare and elusive key, and the reason why no-one has ever ran into this issue is because ConnectBot seems to be the only way to create such keys and use them with sshd. Oh you can absolutely create a key like that with openssl, however, ssh-keygen doesn't seem to be able to read such keys, private or public, in any way, so you can't easily produce the .pub format sshd can use.
When sshlib can't itself import a key, we are trying with Bouncy Castle. For the older RSA etc keys it all works without a hitch as these implement well-known Java interfaces. EdDsa keys are newer and have separate interfaces in Bouncy Castle and sshlib. Sshlib can't import Non-OpenSSH Ed25519 keys itself, so what we end up with a Bouncy Castle-specific key, which is, while very much a valid key, not usable by sshlib. To mitigate that, this adds conversion from BC-specific Ed25519 key to its sshlib-specific variant.
Also, this fixes a bug in our code that created Ed25519 public keys from Ed25519 private keys in a wrong way.
This is a rare and elusive key, and the reason why no-one has ever ran into this issue is because ConnectBot seems to be the only way to create such keys and use them with sshd. Oh you can absolutely create a key like that with
openssl, however,ssh-keygendoesn't seem to be able to read such keys, private or public, in any way, so you can't easily produce the .pub format sshd can use.When sshlib can't itself import a key, we are trying with Bouncy Castle. For the older RSA etc keys it all works without a hitch as these implement well-known Java interfaces. EdDsa keys are newer and have separate interfaces in Bouncy Castle and sshlib. Sshlib can't import Non-OpenSSH Ed25519 keys itself, so what we end up with a Bouncy Castle-specific key, which is, while very much a valid key, not usable by sshlib. To mitigate that, this adds conversion from BC-specific Ed25519 key to its sshlib-specific variant.
Also, this fixes a bug in our code that created Ed25519 public keys from Ed25519 private keys in a wrong way.