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.
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.
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.