As others have pointed out, this doesn't really work, for a couple factors such as the lack of direct TCP connections from the browser, and that the ssh client is for node.

But I also wanted to remind everyone, that even with a javascript implementation that works, you're still trusting the server to give you the correct javascript when the site is loaded. In my mind, this doesn't make moving the crypto any more secure, since to attack you, I can just modify the javascript client on next page load to include a back door. So either way, ShellVault has complete access to your server, because they control the implementation that runs in the browser.

You can’t write a browser-based SSH client on today’s technology without some sort of intermediary. You can’t write to raw TCP sockets.

In the JS projects you listed, the JS SSH client only runs in a Node context, not in the browser, and the TCP proxy would have to be run either on the SSH server or on the client computer. If you’re able to install a Node instance with Websockify on it, I’m sure it would be much more practical to use a traditional SSH client instead.

But yes I agree with you that I wouldn’t trust a service like this because of what I perceive to be a fundamental security issue. But I think they did the best they could with current technologies.

> You can’t write a browser-based SSH client on today’s technology without some sort of intermediary. You can’t write to raw TCP sockets.

Every router between you and the SSH server is an intermediary too. If SSH were terminated at the browser, the websocket-to-tcp proxy provider wouldn't be any more privileged than any other machine on the route.

> the TCP proxy would have to be run either on the SSH server or on the client computer.

It could run on any computer in the world that the client has access to, and that can access the SSH server. (I.e. the same set of computers that could feasibly run the Shellvault server).

Fair point about the SSH client only working in Node. I hadn't looked carefully enough.

There's no fundamental reason why the system I described couldn't work today, it just wouldn't work with the SSH client I linked to.

Maybe I should have said there has to be a trusted intermediary. The underlying SSH protocol is secure from sniffing and man-in-the-middle attacks, so it's okay for there to be any number of untrusted intermediaries (like routers) between the client and host.

Hosting the trusted intermediary is the value proposition Shellvault is proposing, I would imagine. Of course, you could host the same thing yourself. This sort of "self host or pay us to host it" model is very prevalent nowadays.

No, you don't understand.

I'm suggesting that Shellvault could operate an untrusted intermediary by terminating SSH in the browser instead of on their server.

If you don't believe it's possible, load this: https://bellard.org/jslinux/vm.html?url=https://bellard.org/... and use the SSH client. It works already.

You do have to trust Fabrice Bellard not to ship a compromised client to the browser, but a.) that's much less trust than you'd be giving to Shellvault, and b.) there's no reason you couldn't self-host the files for jslinux.

> Shellvault could operate an untrusted intermediary

It's not entirely trivial. The javascript must be served from a trusted source.

JSLinux is not magic - it too does not have raw access to TCP sockets required to terminate SSH in the browser as you think it does.

As described in its FAQ, it uses websocketproxy[1] for network access. This is a separate server application running on https://relay.widgetry.org/ . JSLinux absolutely cannot access raw TCP sockets, and ergo cannot terminate SSH connections, without it connecting to this websocket proxy. You can see this even in the Network tab of devtools.

Sure, you could spin up a websocketproxy yourself, but as I explained in a previous response to you, the value proposition of Shellvault is that you don't need to spin up any servers and host them yourself - this service does it for you.

[1] https://github.com/benjamincburns/websockproxy

As I explained above, the websocketproxy has no more privileged access to your networking than any of the other routers on the internet, whereas Shellvault has plaintext mitm of your entire session. Can you see the difference?

> JSLinux absolutely cannot access raw TCP sockets,

Agreed.

> and ergo cannot terminate SSH connections

No. The SSH application layer is terminated in the browser.

Just tried it out. Used ngrok to tunnel port 22 of my laptop and ssh'd into it from jslinux (my laptop has no public DNS entry and my home network is not on IPv6 yet).

It does work.

Theoretically, yes (see our FAQ [1]), which is why we encourage careful usage. We don't log commands or usage.

We actually looked at a browser-only implementation first. Sadly, there's a limitation on JS SSH: in-browser Javascript can't do SSH, presumably because it lacks the right security code. It needs system-level library support which isn't available except in Chrome's NaCL (which is how Chrome Secure Shell works). The stack you suggested here is a lot like how Shellvault already works, unless I'm missing something -- is there something about this stack that would let us stop being a middleman? It looks to me like the node SSH service would still have to be running somewhere, and our features are designed around being a cloud-only client (there are already lots of good deploy-it-yourself portals that we're not trying to compete with).

[1]: https://www.shellvault.io/documentation/frequently-asked-que...

"We actually looked at a browser-only implementation first."

That leads me to have two questions:

1. Could you do a browser implementation that doesn't send things to you which connects to a proxy on their client or server machine? As in, something they control handled whatever data your machines are handling.

2. If not or as a supplement, could you do paid, shared-source app they could host in arbitrary machine or VM? As in, they could inspect the product, build it from source, and deploy it to trusted hosts. They pay your company mainly for the convenience and updates.

For 1, we're going to look into it (or something like it). It sounds like the service could be improved a lot if we could implement end-to-end encryption without the MitM dangers.

For 2, those kinds of products already exist, and we're not intending to compete with them (consider Apache Guacamole, linked by another commenter somewhere in the thread).

The point about the system I described is that you wouldn't be seeing any plaintext.

It's a mistake that the ssh client requires node, I didn't know that. There's no fundamental reason you couldn't implement an in-browser ssh client the way I described, it's just more work than doing it the way you've done it.

The fact that the person responding for the site does not understand this instantly (or is able to confer with someone who does before responding) makes it very apparent that there is not nearly enough understanding of ssh to be running any type of service like this.

> in-browser Javascript can't do SSH, presumably because it lacks the right security code.

This makes it sound like you don't exactly have any idea what you're doing, which is worrying for a provider of an ssh client.

Javascript is turing complete so there is no reason in-browser javascript couldn't fully implement the ssh protocol, you "just" might have to write or port the appropriate crypto routines to javascript. And of course, you'd need a http/websocket based tcp proxy since you won't be able to do a raw tcp connection to port 22 in a browser.

(Although I'd be extremely wary of using any non-standard ssh client / crypto library implementation - who knows what timing attacks and side channel info leaks might lurk in a less-vetted implementation than openssh)

>is there something about this stack that would let us stop being a middleman?

Yes if you terminate the connection in the browser and your server just acts as a TCP<->websocket proxy, you can verify the fingerprint and (assuming you trust the JS) be sure the proxy isn't MITMing.

> It looks to me like the node SSH service would still have to be running somewhere

No.

Oh, so by "terminate the connection in the browser", you mean the service would connect via SSH to a server, start a separate socket server connected to a terminal, and then hand off the connection entirely to the browser? If not, could you explain what you mean?

If so, I can see some potential issues, but that's a really nice idea for how this could be improved, and I'll look into it more. Thanks (to you and jstanley both)!

I'm not sure I understand what you mean, but the idea is just that the shellvault server is just a dumb pipe. The only thing it does is translate from tcp to websocket and back. You you have some kind of ssh.js that does everything an ssh client does. The only problem is that the browser can't use direct TCP sockets. So instead of SSHing directly into the server you use a websocket to connect to shellvault, and shellvault forwards the data on a TCP socket to the ssh server. And of course takes the data from the TCP sockets and sends it back to the browser via websocket.

That way shellvault acts as a dumb proxy and only forwards encrypted data packets while all the crypto stuff happens in the browser and the ssh server.

Ahh, now I understand. That's worth looking into, thanks!

Not only is it completely possible, pretty sure it's already been done.... https://github.com/stuicey/SSHy

Unfortunately, that project doesn’t yet support key-based auth.

secure password auth trumps "give full access to stranger" auth any day of the week....

Agreed. But since we’re rewriting the implementation in this comment thread there should be an emphasis on E2E encrypted connections WITH key based auth. SSHy packaged up nicely with a web socket proxy through Shellvault, or any provider for that matter, would be more secure than Shellvault’s current implementation but I think the lack of being able to use key based auth would be a nonstarter for many.

While that's better it just shifts the problem: Now you have to trust the JS code you're being sent. If an attacker can hijack their current approach, I would think that sending out modified JS wouldn't be to difficult to do either. The trust root currently when using SSH from your machine is an unmodified and non-hostile SSH client.

True, it's the chicken-egg problem all over again[1].

That said, in theory they could provide a standalone HTML file with all the necessary JS code, which would only do a websocket connection to their servers for the SSH stuff, and would be easier to use in places where you can't install or run binaries. Yes, it could also download malicious code from the server, but then again, so can any ssh binary.

[1] https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

It is possible to create a SRI enforcing bookmarklet and use that to bootstrap the rest of the app from untrusted sources. That way users could drag/drop their current version to the bookmark bar, thereby effectively "installing" and pinning the current version in their browser. See: https://news.ycombinator.com/item?id=17778402