[cntlzw]

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.

[angerson]

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!

[shellshook]

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

[devoply]

> Why is this closed source?

Because free shit don't make money, yo.

[shellshook]

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.

[Skunkleton]

Its not like this hasn't been done before

https://github.com/billchurch/WebSSH2 https://github.com/stuicey/SSHy

[rkeene2]

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

[xorcist]

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.

[omarchowdhury]

I have to agree with this.

[wstuartcl]

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.

[vectorEQ]

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.

[vectorEQ]

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.

[icebraining]

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

[vectorEQ]

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

[michaelmior]

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

[awill]

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.

[pmalynin]

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

[progval]

> 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