snowflake icon indicating copy to clipboard operation
snowflake copied to clipboard

Is ssh ed25519 key supported?

Open tumluliu opened this issue 5 years ago • 10 comments

I have many existing ssh connections for long time and used to connect with terminal. Now I'm trying to migrate to snowflake but could not even create the very first connection. All my keys are ed25519 format. And I just tried with one rsa key, it worked. So I'm thinking about if the ed25519 is not supported (yet).

tumluliu avatar Jan 30 '20 08:01 tumluliu

Thats correct. The underlying ssh library JSch does not support it( only supports DSA and RSA ). But I have plans to add both ECDSA and ED25519 in future.

subhra74 avatar Jan 30 '20 09:01 subhra74

Sounds great. Thank you @subhra74 !

tumluliu avatar Jan 30 '20 15:01 tumluliu

Keeping an eye on this as all my servers only use ed25519. A shame really.

lusky3 avatar Feb 04 '20 22:02 lusky3

Jsch plans in next milestone to support ED25519 : Add support for Ed25519 keys and bcrypt KDF format

But no planned date, nothing since v0.1.55 in 2018-11, code since not really updated actually...

May be https://github.com/hierynomus/sshj as replacement ? Actively maintained and supports ED25519

s-kocher avatar Feb 12 '20 00:02 s-kocher

there are forks of JSCH supporting ED25519 so it must make the switch simple since API must be the same : https://github.com/is/jsch/issues/28

mwiede/jsch

sschlib/sschlib

https://github.com/mwiede/jsch/blob/master/Readme.md#changes-since-fork

Changes since fork: 0.1.61 Add support for [email protected], ssh-ed25519, ssh-ed448, curve448-sha512, diffie-hellman-group15-sha512 & diffie-hellman-group17-sha512. This makes use of the new EdDSA feature added in Java 15's JEP 339. #17 added integration test for public key authentication #19 0.1.60 support for openssh-v1-private-key format opensshFormat.md. Fix bug with AEAD ciphers when compression is used. #15 0.1.59 fixing issue from sourceforge.net/p/jsch/mailman/message/36872566 0.1.58 support for more algorithms contributed by @norrisjeremy see #4 0.1.57 support for rsa-sha2-256 and rsa-sha2-512. #1 0.1.56 support for [email protected]

https://github.com/sschlib/sschlib#features

Key exchange: diffie-hellman-group-exchange-sha1, diffie-hellman-group1-sha1, diffie-hellman-group14-sha1, diffie-hellman-group-exchange-sha256, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521 Cipher: blowfish-cbc,3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc 3des-ctr,aes128-ctr,aes192-ctr,aes256-ctc, arcfour,arcfour128,arcfour256 MAC: hmac-md5,hmac-md5-96,hmac-sha1,hmac-sha1-96 Host key type: ssh-dss,ssh-rsa, ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521

s-kocher avatar Feb 16 '21 00:02 s-kocher

I can speak for the JSch fork available at mwiede/jsch: it should fully support ssh-ed25519 keys starting in release 0.1.61, with the caveat that you must be using Java 15 or newer (as that is the first Java release with EdDSA support from JEP 339).

As the original contributor of the ssh-ed25519 support, If you encounter any issues with it, please raise an issue at mwiede/jsch, making sure to ping me, to ensure that I see it.

norrisjeremy avatar Feb 16 '21 01:02 norrisjeremy

@norrisjeremy thanks for your explanation, I didn't notice the fact it was thanks to the JEP 339 recently added into Java 15.

I cannot speak for snowflake team, just want to help to find a solution, so I don't know if java 15 is a problem or not.

I was looking at some backport of the JEP 339 in older Java versions.

https://java.com/en/jre-jdk-cryptoroadmap.html

Release Date Release(s) Affected Algorithm/Protocol Action Additional Information Change Log
2021-01-19 11.0.10+8 TLS 1.0 to TLS 1.3 Added support for the x25519 and x448 named elliptic curve groups to TLS Adding support for the x25519 and x448 named elliptic curve groups to TLS 2021-01-19 Released.2020-10-09 Announced.

https://github.com/openjsse/openeddsa

OpenEdDSA: A JCE provider that supports KeyPairGenerator, KeyFactory and Signature for the EdDSA crypto algorithms on Java SE 8.

The OpenEdDSA project is created to add support for EdDSA crypto algorithms to existing Java 8 applications without requiring code changes.

The public API for OpenEdDSA is located in the org.openeddsa.java.security.spec and org.openeddsa.java.security.interfaces packages and is similar to the java.security.spec and java.security.interfaces package APIs introduced by JEP-339.

So there is some chance lower versions of Java can benefit it too ?

s-kocher avatar Feb 16 '21 13:02 s-kocher

Hmm, it might be possible to get it to work using something like openjsse/openeddsa, but it would take some work.

The implementation I contributed to mwiede/jsch compiles the ssh-ed25519 support as Java 15 class files and bundles it as part of a multi-release jar. So at a minimum it would require finding a way to compile the ssh-ed25519 support as Java 8 class files instead of Java 15 class files.

Something else to note as well: the implementation of the curve25519-sha256 Kex & [email protected] Cipher I contributed to mwiede/jsch are compiled as Java 11 class files since they are part of JEP 324 & JEP 329.

I'm not sure if the openjsse/openeddsa also includes a backport for those algorithms as well?

norrisjeremy avatar Feb 16 '21 14:02 norrisjeremy

I should also note: the implementation of [email protected] only uses the ChaCha20 implementation from JEP 329 (not the full ChaCha20-Poly1305 implementation).

OpenSSH implemented this cipher differently than the how it is done in TLS for RFC8439, and it's not possible to fully create an OpenSSH compatible implementation in Java purely using JEP 329, since the JEP 329 version is only compatible with RFC8439.

To overcome this hurdle, we combined the ChaCha20 base cipher from JEP 329 with the Poly1305 implementation from OpenJAX located here: https://github.com/openjax/security/blob/master/nacl/src/main/java/org/openjax/security/nacl/Poly1305.java.

norrisjeremy avatar Feb 16 '21 14:02 norrisjeremy

@subhra74 , can I ask if you are willing to switch to the fork of Jcsh with ed25519 support? I am sure one of us would be willing to PR this feature provided it is acceptable to depend on a different Jcsh as well as JDK 15 if necessary.

I will note that JDK 16 strongly encapsulates JDK internals by default, so if muon has any libraries which require such access users would have to run with --illegal-access=permit. Other than that, I don't foresee any challenges using JDK 15 or 16 for muon.

A248 avatar Mar 21 '21 17:03 A248