Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Shellvault – Cloud SSH terminal accessible from any browser (shellvault.io)
114 points by angerson on Jan 10, 2019 | hide | past | favorite | 101 comments

I don't want to be cynical. There is probably lots and lots of work being put in this project, but....

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.

Many other commenters have expressed similar misgivings, but I'll respond to this top-rated one so that I don't pollute the thread.

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.


The only way this software even remotely makes sense is as a self-hosted open source product. Why is this closed source?

> Why is this closed source?

Because free shit don't make money, yo.

Neither does an obviously flawed business model. I can't imagine ever wanting to use this as-is. Horribly insecure.

If it was self hosted and open there'd at least be the tiny chance of a support contract.

I've been using gotty with great success for a while.

The truly evil business model would be to offer this as a free service. The company would be set up for a very profitable acquisition just by their placement in their customer's data streams.

I have to agree with this.

I don't think I would call the services problem the "MitM aspect" -- that is literally the largest point of value an ssh connection gives you -- its primary reason for being used is to stop MitM snooping/collection and takeover (of traffic and auth). Like most all of ssh's design is specifically crafted to reduce the risk of MitM. This offerings design basically tosses that out of the window.

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

if you cannot 'see' the commands and passwords etc., then a malicious interuder can also not see it. you need to build it with in mind that you will be owned. if you design it like that, then most of the complaints you have gotten are invalid. it can be that you yourself are trustworthy and good person, but this doesn't say that there might be unknown vulnerabilities in your code or infrastructure. once someone is on the box, they can see the same as you, but they might not be so kind as to drop the information.

i do want to be cynical: sed -i -e 's/#Port 22/Port 443/g' /etc/ssh/sshd_config

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.

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

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.

its funny this came to my mind thinking about it but i wasn't aware it already existed. thanks for that.

> a normal configuration could solve it

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.

correct. You still need a client. The Op is probably referring to getting around firewall restrictions. Some companies block all outbound ports except p80 and p443, so if you work at such a company, you can't access your personal machine over p22. Shellvault lets you do that on p443. But so does changing your SSH server to listen on p443.

A self hosted version of this might make a little more sense. However, it is still putting all your credentials in one place.

I mean there is also Teleport (Gravitational) that you could self host and get around most of those issues.

> if the server is also hosting some https website, then put it on an alternate ipv6 address

Or use sslh if you're stuck on IPv4

> Shellvault uses a websocket to connect a client-side terminal emulator to an SSH process on Shellvault's servers. When you type a command, it goes through the websocket to the SSH client running on our servers, and the socket sends the response back to the terminal in your browser.

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

As others have pointed out, this doesn't really work, for a couple factors such as the lack of direct TCP connections from the browser, and that the ssh client is for node.

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.

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.

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.

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

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.

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.

> Shellvault could operate an untrusted intermediary

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

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

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,


> and ergo cannot terminate SSH connections

No. The SSH application layer is terminated in the browser.

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.

Theoretically, yes (see our FAQ [1]), which is why we encourage careful usage. We don't log commands or usage.

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

"We actually looked at a browser-only implementation first."

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 1, we're going to look into it (or something like it). It sounds like the service could be improved a lot if we could implement end-to-end encryption without the MitM dangers.

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

The point about the system I described is that you wouldn't be seeing any plaintext.

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.

The fact that the person responding for the site does not understand this instantly (or is able to confer with someone who does before responding) makes it very apparent that there is not nearly enough understanding of ssh to be running any type of service like this.

> in-browser Javascript can't do SSH, presumably because it lacks the right security code.

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)

>is there something about this stack that would let us stop being a middleman?

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


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)!

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.

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

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

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

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

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.

While that's better it just shifts the problem: Now you have to trust the JS code you're being sent. If an attacker can hijack their current approach, I would think that sending out modified JS wouldn't be to difficult to do either. The trust root currently when using SSH from your machine is an unmodified and non-hostile SSH client.

True, it's the chicken-egg problem all over again[1].

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

It is possible to create a SRI enforcing bookmarklet and use that to bootstrap the rest of the app from untrusted sources. That way users could drag/drop their current version to the bookmark bar, thereby effectively "installing" and pinning the current version in their browser. See: https://news.ycombinator.com/item?id=17778402

This is completely insecure sorry. A cautionary tale of how this works in reality if this product is successful is to look at hushmail, one of the first ultra-popular webmail sites that provided end-to-end encryption from Canada (via a java applet) -- they updated their terms and services after many years of running and fighting US court orders with this statement:

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


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

I can see how this might seem convenient, but using this service would be a really bad idea. The vendor even seems to know this:

    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.
Unfortunately, this only means that Shellvault creates the private key itself. Which amounts to "sharing your private key".

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.

This is described as "like Chrome Secure Shell", but the major difference is that with the Chrome Secure Shell application, the ssh client runs in the browser, so it's actually secure; where as Shellvault is an architected (by design) man-in-the-middle attack.

Advice: if you can use Chrome Secure Shell, you should do so.

Our goal is to provide a useful service for anyone who wants to be able to log in from anywhere, which does unfortunately mean we're stuck as a potential MitM. We wrote a lot of documentation about how to mitigate the security issues [1], but ultimately we encourage anyone with security on the mind to use their own SSH client.

[1]: https://www.shellvault.io/documentation/security-best-practi...

This feels like, some people that make cool apps decided to get into security, nothing I've read here makes me believe you really had a security hat on as you made this and that worries me.

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.

Sorry but I have a trust issue with this kind of service. Saying that you don't log anything is one thing but believing it is something else. Even hosting this kind of web service on the server I try to access would be a "no" for me. But that would be a bit more acceptable for some use cases for other people.

Right, Shellvault isn't for everyone: we're aiming to provide a good service for anyone who wants more convenience than normal SSH can provide, and we've worked hard on transparently documenting security considerations and adding features that don't compromise on privacy.

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!

Looking good, you're right it's not for everyone but it will be the right solution for some, so don't get discourage from these mostly negative (rightly) comments. I see you comparatively to Serverpilot which is another server management for dummys type of service, they have made themselves a nice niche in the novice website admin community, which is where I see your service succeeding. Having said that one reason for the success of Serverpilot is that the founders had excellent reputation in the dev community as long time Microsofties, but browsing Shellvault I see no information who is behind the service. I have no idea who you are and that's what makes me hesitant about using your service. Some background info would help. BoL.

Thanks a lot for your advice and kindness. We've been hesitant to overuse industry credentials (I work at Google) because I personally look for documentation quality over goodness-by-association, but I agree that we haven't done enough to answer the question of "who is this, and why should I trust them?". You are right that having too little identity does not help the service look better, so we'll take another look at this.

This should not be a thing, I’m sorry. You’re selling an exploit as a paid service and I don’t even want to take the chance that a junior developer will fall for it.

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.

Hey HN! Shellvault is a project I've been working hard on for a few months now. It's a cloud service that allows you to SSH from the comfort of any browser similar to Chrome Secure Shell, but with many more features. Shellvault is still young and I'd love to hear what you think about it. I put a lot of effort into encouraging best security practices both for our clients and on our own servers. I'll be here to respond to any questions or comments you have. Thanks!

This look nice, amazing really. However, like others have pointed out, some people may be uncomfortable giving a 3rd party a doorway into their systems.

Is a self-hosted version on the roadmap?

Very cool. Have any plans to enhance mosh support?

Sure, what kind of enhancements do you have in mind? Mosh and regular SSH are both supported right now (you can choose which one to use on a per-server basis), but we haven't implemented any advanced toggles yet aside from setting the connection port.

You can get something very similar using AWS Cloud9. You can make Cloud9 workspaces that are full IDEs, which also includes terminal access. If you use your Cloud9 workspace as just a frontend to you own server (using SSH), it's free (besides the likely negligible data transfer), and it can be any server you want, not just on AWS. If you use your Cloud9 workspace bundled to a new EC2 Server, you pay the normal hourly cost of the server, and can have it shut itself off when it's idle.

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.


I want to say first that I applaud you for the time and effort to build something. Getting of your duff and building something is awesome.

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.

To be honest, I think I might almost consider using this if it were self-hosted, but even then it would be a fairly scary thing.

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

Why is it no different when you use iTerm?

Someone else wrote iTerm. Using it as an SSH client is trusting that the author is benevolent rather than malicious.

I mean, 99.9% of SSH users are going to be using an SSH client written by someone else....

Isn't the 'self-hosted' version of this application your local SSH client plus an admin VPN?

I think I would pay good money for that web client though, it looks very neat.

It’s all a matter of convenience :)

For a self-hosted alternative: https://guacamole.apache.org/

I think the biggest feedback item for me would be that most of the servers I access are on an internal network and firewalled off from external access. Which is not uncommon when you get into an enterprise setting (where this is useful)

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

Thanks for the feedback! This is something we've had in mind for a while, and we're hoping to get to work on enterprise support (including other features like key sharing between team users and usage auditing) after solidifying the platform for independent users. It'll be easier to add proxy support, but I agree that a possible opening like that isn't going to cut it.

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.

Nice. Here is an open-source, self-hosted option: https://github.com/paradoxxxzero/butterfly

Neat looking service. From a security standpoint, it is a bit terrifying that it could be logging everything, no?

That's right. That's one of the big security considerations we've had in mind from the start, so we've provided a lot of documentation and notices about what we do and don't track [1] and how to use Shellvault while building strong security habits. We've done our best to be upfront about privacy throughout the site.

We don't log any SSH usage details, ever.

[1]: https://www.shellvault.io/policies/privacy-policy/

"We've provided instructions on how to keep your servers safe in the events of a Shellvault data breach. We're not liable for compromised servers that result from not implementing these policies."

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?

Yikes, that's a typo on the homepage. It'll be fixed in a few minutes once Cloudfront updates, thanks!

Pretty much any device these days can run some form of standalone SSH software or, worst case scenario, a shell + openssh (heck, even Windows can do that these days).

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.

1. This is very, very cool looking.

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?

Thank you for saying so. We've put a lot of work into just getting to this state, and next for us comes a lot more work on both features and security, like you said.

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.

Dismissing such basic security concerns as "extremely high standards" is quite off-putting. You need to earn a very, very high level of trust to successfully run such a service, as the other comments in this thread clearly show, and this comment does the opposite, at least for me.

It is hard to imaging that you interviewed any potential users of such a system before building it. You are solving a problem users do not have in a way that creates problems for users.

I'm planning on launching something similar-ish in the next couple of weeks, so your feedback would be tremendously appreciated.

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

Anyone who works for the NSA or a hacker group would agree that all that free user data has pretty great value.

What about using Google Cloud Shell (https://cloud.google.com/shell/docs/; free, open to anyone with a Google account) as a jump host to your servers? Or using GCE's ssh-in-the-browser feature (https://cloud.google.com/compute/docs/ssh-in-browser) to connect to your own GCE VM (not free, in this case) and using it as jumphost?

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.

Azure also has a similar feature (https://azure.microsoft.com/en-ca/features/cloud-shell/) with built in VS code based IDE.

Cloud shell allows Google to see what I type on the shell machine. So if I ssh from there into the target, nothing is gained and it's MITMable by Google. The only difference is that it's less likely to happen.

That's fair. Although there are pretty tight internal controls on what Google can do on your Cloud Shell, you have to put a certain level of trust into Google here. Getting your own GCE VM and using SSH-in-the-browser is arguably more secure. Last I checked an f1-micro VM would suffice and fits under the 'always free' GCE cap.

I would like something like this, but open source (my inspiration is codebox.io, which is dead). I might code it actually. My goal would be to have an easy editor, file manager and shell for Docker images that could be installed in one line of bash.

I read codesandbox and was confused why it's dead

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

Note to self: revoke ssh keys of users found to be using this.

I use gotty https://github.com/yudai/gotty, which works great.

You could pay 5$ for this service. Or you could pay 5$ for a virtual server that can be secured off by yourself and still use reverse proxies on ssh to access any machine...

Since a lot of people here have a technical background the most popular choice should be apparent.

This reminds me of Dropbox, but with the difference that Dropbox was for non-developers, whom does not know how to share files. Most developers already know how to use SSH, so what is the main selling point for this service !?

Everyone I've seen using something like this or Google cloud shell is doing it to get around oppressive corporate proxies to get some kind of work done.

Proxies like Forcepoint/Websense are content-aware enough that simple tricks like having sshd listen on port 443 don't work.

The big one is convenience: if you need to do some quick maintenance from a computer you're not usually using, it's fast and easy to do so here (e.g. if you want to administer your server from a firewalled work PC, or from your parents' house).

Maybe consider offering a self-hosted option - even if it's a paid one, it'd be a nice alternative to things like ajaxterm.

I actually thought this looked great until I realized that it was a hosted service.

I use google cloud console which is also browser based ssh console. Its free with gooogle cloud account. I can then ssh to other servers. So this service makes no sense for me.

I need to create account to test? No Thanks.

Yeah, sorry for the inconvenience. We added a registration requirement to prevent anyone from abusing the free trial so easily, although it would have been a nice idea to have a demo available.

did you-guys reuse any code from https://guacamole.apache.org/ or all home grown ?

Shellvault was developed from scratch with Laravel and Vue.js (the terminal is XTerm.js [1]). One of our big design ideals while developing Shellvault was that setup should be just as easy as a standard SSH client, so there's nothing new you need to install server-side to use it.

[1]: https://xtermjs.org/

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact