Show HN: Shellvault – Cloud SSH terminal accessible from any browser
shellvault.io
shellvault.io
The business idea is basically this: hand me your credit card, I go to your favorite ATM, get some money and hand it to you. It is great service!
Yes, a great service for some, but why would I give the most sensible credentials I own to a third-party? SSH tries to avoid man-in-the-middle attack. This is a man-in-the-middle attack as a service.
on a more serious note, as you described but maybe from a more grumpy person: i don't think it's a great service, as it just compromises credentials by default while a normal configuration could solve it.
if the server is also hosting some https website, then put it on an alternate ipv6 address (they are free if not cheap) and ssh into that. you only need to edit 2 files on your server for that to work :s why pay 5$ a month if you already have a capable server you are paying for??
the promise of not storing credentials etc. is nice, but if your servers are compromised it will be childsplay for efarious people to intercept them even if you didn't design that aspect to happen in the service design.
Could you explain what you mean by this? I get not everyone wants this, but just making SSH listen on port 443 doesn't give you access on a computer without an SSH client.
A self hosted version of this might make a little more sense. However, it is still putting all your credentials in one place.
There's also sslh, which can multiplex the same port by detecting whether the incoming connection is TLS or SSH, and forwarding appropriately. It's pretty cool: https://www.rutschle.net/tech/sslh/README.html
That said, I think this service is for people who need to use computers without ssh clients installed locally.
Or use sslh if you're stuck on IPv4
First, thanks for your brutality. It's good to know that a service like this (which deals with such sensitive content) is treated suspiciously at first.
Second, a few commenters have shown that it may be possible to reduce the MitM aspect by pushing more work into the browser with a method that could also provide end to end encryption. We're going to look into this thoroughly because we thought it was impossible at first, but I'm also curious if that would change your mind at all about using the service. At the very least, it would improve our users' security, so we're still going to see if we can do it.
Third, I do want to emphasize that we encourage users to create multiple keys to use, so that they have lots of power over granting and revoking server access via those keys (kind of like a new proxy credit card in your example, I guess). There are lots of ways a service like Shellvault could accidentally encourage poor habits, and we're working very hard to encourage good ones instead.
Thanks!
Because free shit don't make money, yo.
If it was self hosted and open there'd at least be the tiny chance of a support contract.
https://github.com/billchurch/WebSSH2 https://github.com/stuicey/SSHy
* You hand over the keys to the castle (multiple keys or not -- thats irrelevant) * You specifically route traffic through a midpoint that by all means has access to inspect the traffic. You have to trust both that the operators of the service will not do this AND that there is no compromise of the service with no way to verify.
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
Step 2: websocket tcp proxy - https://github.com/novnc/websockify
Step 3: javascript terminal emulator - 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/ which actually already works today
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-que...
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.
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.
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)!
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.
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.
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).
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)
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.
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.
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.
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.
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.
> JSLinux absolutely cannot access raw TCP sockets,
Agreed.
> and ergo cannot terminate SSH connections
No. The SSH application layer is terminated in the browser.
It does work.
It's not entirely trivial. The javascript must be served from a trusted source.
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.
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/b...
"Hushmail is a web-based service, the software that performs the encryption either resides on or is delivered by our servers. That means that there is no guarantee that we will not be compelled, under a court order issued by the Supreme Court of British Columbia, Canada, to treat a user named in a court order differently, and compromise that user's privacy."
https://www.wired.com/2007/11/hushmail-to-war/
To hushmails credit, they were making a protocol that was insecure by default a bit more secure.
Shellvault is doing the opposite which is not commendable
Sharing your public key is ok, but you should never
share your private key (from the file id_rsa) with
anyone. Instead, we've made it easy to create new
Shellvault-specific keypairs.
The lack of an end-to-end encryption tunnel means that despite the vendor's best intentions, this service introduces a lot of points at which a malicious actor (or accidental misconfiguration) could compromise your session.
In short, there are multiple good, free, native, and local SSH clients and terminal emulators for every platform. Use those instead.
Advice: if you can use Chrome Secure Shell, you should do so.
[1]: https://www.shellvault.io/documentation/security-best-practi...
SSH is one of the most fundamentally critical pieces of a corporate infrastructure, the people I work with would absolutely not stop laughing if I told them this wasn't a joke. If you were selling an open source host-it yourself, support contract type model, I could totally see interest in this, but not a whole lot because if I have a device with a browser, there's a 99% chance it also has a terminal client/emulator.
The next issue here is, you telling everyone you don't log anything is instantly a fail, because if its even _possible_, then it's not good enough.
Saying you don't log anything doesn't matter because you can be compelled to, or you can be intercepted, MiTMd or just plain exploited.
I don't see any value in another thing to pay for every month that by design _decreases_ your security; I already hate the everything as a service for personal use, no problem with it professionally, but SSH needs to keep moving forward not have gaping holes added in the middle.
For personal use I have it solved with a VPN + terminal emulator, or it could be done with a VPS and some open source code.
I'm sorry to be so blunt like other people here, but rather than see this fail I'd like to hope the chorus of opinions here would encourage you to rethink your model and actually make this something secure.
We've done a lot to try and work on trust, but that won't truly come without a good record of contented customers. Hopefully we can work hard and impress you!
Literally no amount of documentation is going to justify having private keys to other people’s servers.
One of the ways to fix it would be to open source ALL the code, let people self host it if they want to. You get to see your work live on atleast.
Is a self-hosted version on the roadmap?
So Cloud9 does the same thing, plus file editing in your browser, for pretty much free. And while Amazon isn't perfect, I trust their security more than a random site.
That said, this product is a man-in-the-middle attack on SSH. You're a prime target for hackers. Expect to be hyper vigilant on everything have built, from your application to your website, since you're now owning the security for users.
Giving someone else control over my shell sessions just seems like a spectacularly bad idea (though I guess it’s no different when I use iTerm).
I think I would pay good money for that web client though, it looks very neat.
So, my suggestion is to-do one of two things:
1. Create a gateway service which makes an effective reverse proxy into the network. Wouldn't fully recommend this option as many enterprises will see this a a huge hole in their networks.
2. Create a version of this which can be deployed to the internal network, and not have any connection to the cloud instance. Business models for this would probably be per-user licenses, and probably the best idea if you want to bring in the big bucks™️.
Another possible option is OAuth integration with cloud platforms like AWS or GCP, which more and more companies (including mine) are starting to use more often -- but they're still a minority compared to internal networks.
We don't log any SSH usage details, ever.
Will you accept liability for compromised servers that result from a fault in your code, service or practices when the policies you recommend are implemented in accordance with your documentation?
Setting these up is fairly painless, and they are FAR more flexible than this solution, FAR more secure and the vast majority are open source - which is KINDA important when dealing with security.
Sorry for being blunt, but all I see here is a huge gaping security hole. The $5/month is just adding insult to injury.
2. We would never in a million years sign off on any usage of this at any of our clients.
I think there's something of pretty great value here, but am skeptical of the multitenant SAAS packaging it has now. No serious firm can reasonably hand off SSH access to a third party like this.
Also: where's your security page? What verification work has been done on this?
Our focus right now is on independent users who are looking for convenience, since we can't expect to fully support larger groups who have extremely high standards that we can't yet meet.
Edit: Apologies, I didn't intend to dismiss rightfully high security expectations as "extremely high standards". To put it another way, we have to start somewhere, and we've put plenty of work already into the basics, but our obvious next steps are to step up on security while also supporting users who are already willing to use Shellvault as-is. My above comment should have said that we don't yet have the resources to properly support enterprise-grade security concerns.
> I think there's something of pretty great value here
What specifically do you think has great value? Is it the nice web-based UX? Something else?
Both Cloud Shell and SSH-in-the-browser use an in-browser SSH client, so the connection is encrypted all the way and not MITMable.
p.s. full disclosure: I work at Google on the team that maintains both of the above.
But yes, it would be very nice if it was self hosted and doesn't seem too hard to implement (if you go for the minimum viable product, which is just a terminal), could even run in an docker container that ssh's into the host
Since a lot of people here have a technical background the most popular choice should be apparent.
Proxies like Forcepoint/Websense are content-aware enough that simple tricks like having sshd listen on port 443 don't work.
I actually thought this looked great until I realized that it was a hosted service.
[1]: https://xtermjs.org/