angerson

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.

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.

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.

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.

Thanks!

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

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

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

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.