3 ms·

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 termi

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
    - bronco21016 8y ago
      Unfortunately, that project doesn’t yet support key-based auth.
      - Vendan 8y ago
        secure password auth trumps "give full access to stranger" auth any day of the week....
        bronco21016 8y ago
        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.

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
  - bronco21016 8y ago
    Unfortunately, that project doesn’t yet support key-based auth.
    - Vendan 8y ago
      secure password auth trumps "give full access to stranger" auth any day of the week....
      - bronco21016 8y ago
        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.