5 ms·

> Shellvault uses a websocket to connect a client-side terminal emulator to an SSH process on Shellvault's servers. When you type a command, it goes through the

> Shellvault uses a websocket to connect a client-side terminal emulator to an SSH process on Shellvault's servers. When you type a command, it goes through the websocket to the SSH client running on our servers, and the socket sends the response back to the terminal in your browser. So this gives Shellvault complete shell access to your server. It could be improved by terminating SSH at the browser, and just using the Shellvault server as a dumb proxy. Step 1: javascript ssh client - https://github.com/mscdex/ssh2 https://github.com/mscdex/ssh2 Step 2: websocket tcp proxy - https://github.com/novnc/websockify https://github.com/novnc/websockify Step 3: javascript terminal emulator - https://github.com/rohanchandra/javascript-terminal https://github.com/rohanchandra/javascript-terminal Step 4: ??? Step 5: Profit EDIT: And a really roundabout way to do this is to run the dropbear ssh client inside Fabrice Bellard's in-browser Linux VM: https://bellard.org/jslinux/ https://bellard.org/jslinux/ which actually already works today

angerson 8y ago
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-questions/#can-shellvault-read-the-commands-i-send-are-they-logged- https://www.shellvault.io/documentation/frequently-asked-que...
- jstanley 8y ago
  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.
  - wstuartcl 8y ago
    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.
- lawl 8y ago
  >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.
  - angerson 8y ago
    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)!
    - lawl 8y ago
      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.
      - angerson 8y ago
        Ahh, now I understand. That's worth looking into, thanks!
        Vendan 8y ago
        Not only is it completely possible, pretty sure it's already been done.... https://github.com/stuicey/SSHy https://github.com/stuicey/SSHy
- nickpsecurity 8y ago
  "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.
  - angerson 8y ago
    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).
- 0x0 8y ago
  > 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)
invokestatic 8y ago
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.
- jstanley 8y ago
  > 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.
  - invokestatic 8y ago
    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.
    - jstanley 8y ago
kevin_nisbet 8y ago
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.
- deleted 8y ago
  [deleted]
dividuum 8y ago
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.
- icebraining 8y ago
  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/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
  - dividuum 8y ago
    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 https://news.ycombinator.com/item?id=17778402

angerson 8y ago

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-questions/#can-shellvault-read-the-commands-i-send-are-they-logged- https://www.shellvault.io/documentation/frequently-asked-que...

jstanley 8y ago
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.
- wstuartcl 8y ago
  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.
lawl 8y ago
>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.
- angerson 8y ago
  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)!
  - lawl 8y ago
    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.
    - angerson 8y ago
      Ahh, now I understand. That's worth looking into, thanks!
      - Vendan 8y ago
        Not only is it completely possible, pretty sure it's already been done.... https://github.com/stuicey/SSHy https://github.com/stuicey/SSHy
nickpsecurity 8y ago
"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.
- angerson 8y ago
  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).
0x0 8y ago
> 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)

invokestatic 8y ago

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.

jstanley 8y ago
> 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.
- invokestatic 8y ago
  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.
  - jstanley 8y ago

kevin_nisbet 8y ago

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.

deleted 8y ago
[deleted]

dividuum 8y ago

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.

icebraining 8y ago
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/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
- dividuum 8y ago
  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 https://news.ycombinator.com/item?id=17778402