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