

SSH2 client written in pure JavaScript for node.js - coenhyde
https://github.com/mscdex/ssh2

======
ibotty
ssh is pretty hard to do right. i will never get, why platforms have to stay
"pure"... and implement everything on earth another time within their platform
instead of calling reasonable external c-code (or anything else for that
matter). i bet this implementation does not parse .ssh/config correctly
either.

~~~
coenhyde
I'll tell you why. Because the c-libs probably block and having dependencies
that have to be compiled increases the risk of something going wrong.

Why should this library parse .ssh/config? This is an application level
library. IMO it shouldn't be reading .ssh/config at all.

~~~
ibotty
"having dependencies that have to be compiled increases the risk of something
going wrong".

come on. reimplementing crypto is way worse.

re .ssh/config: application level libraries might need it as well. one of the
many grieves i have about mysql-workbench (or any other java tool that does
ssh), is that i have to configure keys and hostnames in it another time.
multihop does not even work in them. both is easy in .ssh/config.

~~~
andreyvit
Re .ssh/config, this only makes sense for cli tools.

If you're on a Mac and writing a desktop sandboxed GUI app, reading
.ssh/config isn't even an option. Same for W8 Metro apps (if those can even
contain a Node.js runtime; not sure about that).

And if you're using an ssh lib on a web site to access user-provided data
using user-provided credentials, you most certainly don't need .ssh/config.

~~~
ibotty
why? what about the usecase i presented? mysql-workbench is no cli app. still,
i'd like it to support multi-hop. and it should do so without me configuring
it separately.

edit: to make this more clear. of course a heavily sandboxed app might not
support .ssh/config. but it should not be able to read my keys as well. so i
don't really see the point. a web-app is a very different thing. but node is
not only about web apps anymore.

------
jebblue
Am I the only one who thinks JavaScript should be confined to the browser for
strategic maintenance purposes?

~~~
camus
node javascript and browser javascript are 2 different things. the javascript
node uses is pretty decent , and as ES6 kicks in it will be a language as good
as PHP (even better , since it will not have all the java inspired non sens
php has). On the client , javascript is pretty much stuck since you need to
support a wide range of browsers.

