[jstanley]

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

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]

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.

[xorcist]

> Shellvault could operate an untrusted intermediary

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

[invokestatic]

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

[jstanley]

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.

[seletz]

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.