Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenSSL crypto lacks standard ed25519 crypto support for ssh, etc #2144

Closed
ghost opened this issue Jul 9, 2015 · 6 comments
Closed

OpenSSL crypto lacks standard ed25519 crypto support for ssh, etc #2144

ghost opened this issue Jul 9, 2015 · 6 comments
Labels
crypto Issues and PRs related to the crypto subsystem. openssl Issues and PRs related to the OpenSSL dependency.

Comments

@ghost
Copy link

ghost commented Jul 9, 2015

I'm currently running

    node -v
        v0.12.6
    npm -v
        2.11.2

I've built/usr 'atom' editor, v1.0.0

I've installed an SFTP connector pacakge in 'atom' editor (https://github.com/mgrenier/remote-ftp).

It fails to connect when using an off-the-shelf, OpenSSH-generated ed25519 key for for authentication,

    Uncaught Error: Cannot parse privateKey: Unsupported key format

Per the stack trace, that error originates with the used 'ssh2' (https://github.com/mscdex/ssh2) lib,

    At /home/pgnd/.atom/packages/Remote-FTP/node_modules/ssh2/lib/client.js:147

        Error: Cannot parse privateKey: Unsupported key format
          at Client.connect (/home/pgnd/.atom/packages/Remote-FTP/node_modules/ssh2/lib/client.js:147:13)
          at ConnectorSFTP.module.exports.ConnectorSFTP.connect (/home/pgnd/.atom/packages/Remote-FTP/lib/connectors/sftp.js:78:13)
          at Client.module.exports.Client.connect (/home/pgnd/.atom/packages/Remote-FTP/lib/client.js:198:18)
          at Client.<anonymous> (/home/pgnd/.atom/packages/Remote-FTP/lib/views/tree-view.js:178:28)
          at /home/pgnd/.atom/packages/Remote-FTP/lib/client.js:87:14
          at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:379:3)

which, in turn,

"... does not support ed25519 keys because node.js/io.js currently only supports RSA and DSA keys for the purposes of its crypto API (especially signing and verifying). ..."

As per the current OpenSSH 6.9p1 ChangeLog, ed25519 support has been fully supported for quite awhile, and is in fact being used as default crypto in some cases,

    commit d1958793a0072c22be26d136dbda5ae263e717a0
    Author: djm@openbsd.org <djm@openbsd.org>
    Date:   Thu May 28 04:40:13 2015 +0000

        upstream commit

!!      make ssh-keygen default to ed25519 keys when compiled
         without OpenSSL; bz#2388, ok dtucker@

        Upstream-ID: 85a471fa6d3fa57a7b8e882d22cfbfc1d84cdc71

    commit 1195f4cb07ef4b0405c839293c38600b3e9bdb46
    Author: djm@openbsd.org <djm@openbsd.org>
    Date:   Thu Jan 8 10:14:08 2015 +0000

        upstream commit

        deprecate key_load_private_pem() and
         sshkey_load_private_pem() interfaces. Refactor the generic key loading API to
         not require pathnames to be specified (they weren't really used).

        Fixes a few other things en passant:

!!      Makes ed25519 keys work for hostbased authentication (ssh-keysign
        previously used the PEM-only routines).

        Fixes key comment regression bz#2306: key pathnames were being lost as
        comment fields.

        ok markus@

    commit 1f0311c7c7d10c94ff7f823de9c5b2ed79368b14
    Author: Damien Miller <djm@mindrot.org>
    Date:   Thu May 15 14:24:09 2014 +1000

           - markus@cvs.openbsd.org 2014/04/29 18:01:49
             [auth.c authfd.c authfile.c bufaux.c cipher.c cipher.h hostfile.c]
             [kex.c key.c mac.c monitor.c monitor_wrap.c myproposal.h packet.c]
             [roaming_client.c ssh-agent.c ssh-keygen.c ssh-keyscan.c ssh-keysign.c]
             [ssh-pkcs11.h ssh.c sshconnect.c sshconnect2.c sshd.c]
!!           make compiling against OpenSSL optional (make OPENSSL=no);
             reduces algorithms to curve25519, aes-ctr, chacha, ed25519;
             allows us to explore further options; with and ok djm

    commit 9c36698ca2f554ec221dc7ef29c7a89e97c88705
    Author: Tim Rice <tim@multitalents.net>
    Date:   Fri Mar 14 12:45:01 2014 -0700

        20140314
!!       - (tim) [opensshd.init.in] Add support for ed25519

ed25519 (http://ed25519.cr.yp.to/) is both fully supported & keys are widely used in openssh deployments.

Without like support in node.js/io.js, downstram pacakges/apps based on its crypto will not be able to connect to these now standard deployments using ed25519 keys.

@bnoordhuis
Copy link
Member

I think you may be mistaking openssh with openssl? Crypto in io.js (and node.js) is provided by openssl, not openssh, and openssl doesn't support ed25519. You can get the list of supported curves with crypto.getCurves().

@ghost
Copy link
Author

ghost commented Jul 9, 2015

well, the problem manifests in a failure to make an SFTP connection with a node.js-based packaed, using an openSSH ed25519 key.

@ icetee/remote-ftp#143,

I was told by one of the node.js/io.js committers:

"ssh2 currently does not support ed25519 keys because node.js/io.js currently only supports RSA and DSA keys for the purposes of its crypto API (especially signing and verifying)."

I don't know yet where any 'fault' lies. I only know so far that a node.js-based package can't connect using current Openssh keys, and that I was told it's a crypto problem.

Happy to learn what/where the fix is ...

If node.js/io.js is limited to only openssl's Curve25519, it may be possible to add ed25519 support by internal conversion of users' "standard" openssh keys to node's "internal" form using an openfork of NaCL

Ed25519 to Curve25519 keys conversion
http://doc.libsodium.org/advanced/ed25519-curve25519.html

fwiw, given M$'s recent investment in / commitment to Openssh as its SSH-tech
(http://blogs.msdn.com/b/powershell/archive/2015/06/03/looking-forward-microsoft-support-for-secure-shell-ssh.aspx) there's soon going to be a fair number MORE folks with ed25519 openssh keys ...

@bnoordhuis
Copy link
Member

Maybe the ssh package works for you? It's either that or wait until openssl grows ed25519 support. That probably won't be anytime soon, it's a pretty conservative project.

@ghost
Copy link
Author

ghost commented Jul 9, 2015

fyi, there's also available now,

Implementations of a fast Elliptic-curve Digital Signature Algorithm
https://github.com/floodyberry/ed25519-donna

Wherein it states

"No configuration is needed if you are compiling against OpenSSL."

Ignoring the facts that (1) Openssh is widely used, (2) ed25519 crypto is widely used (http://ianix.com/pub/ed25519-deployment.html), and (3) Openssl is (as you point out) quite conservative leaves end-users in a bit of a bind. Might be worth some additional consideration in node/io

WILL take a look at the 'ssh' lib ...

@ghost
Copy link
Author

ghost commented Jul 9, 2015

It looks like the work's already been done in large part here,

An Ed25519 implementation for node.js
https://github.com/dazoe/ed25519

and more notably, here

Port of the lib sodium encryption library to Node.js
https://github.com/paixaop/node-sodium

@Fishrock123 Fishrock123 added the openssl Issues and PRs related to the OpenSSL dependency. label Jul 22, 2015
@Fishrock123 Fishrock123 changed the title io.js crypto lacks standard ed25519 crypto support for ssh, etc. OpenSSL crypto lacks standard ed25519 crypto support for ssh, etc Jul 22, 2015
@ghost ghost closed this as completed Jul 24, 2015
@Ayfri
Copy link

Ayfri commented May 13, 2024

Still not able to use ed25519 keys with ssh-2 library today

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
crypto Issues and PRs related to the crypto subsystem. openssl Issues and PRs related to the OpenSSL dependency.
Projects
None yet
Development

No branches or pull requests

4 participants