[angerson]

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]

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]

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

[Vendan]

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

[bronco21016]

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

[Vendan]

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

[bronco21016]

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.