angerson

This is a nice write-up. I recently added post-to-bluesky support to my ongoing social-media-scheduler project [1], thinking it would be the simplest of the services to work on, but I ended up getting really confused instead.

DID and handle resolution was the easiest part of ATProto---as the author says, a library can do the job easily. For Ruby it's DIDKit [2]. Where ATProto really threw me was the seeming non-ownership of record types. Bluesky uses "app.bsky.feed.post" for its records, as seen in the article; there seem to be a lot of these record types, but there doesn't seem to be a central index of these like there are for DIDs, or a standard way of documenting them... and as far as I've been able to find, there's no standard method of turning an at:// URI into an http:// URL.

When my app makes a post on behalf of a user, Bluesky only sends an at:// URI back, which I have to convert myself into an http:// URL to Bluesky. I can only do that with string manipulation, and only because I know, externally, what format the URL should be in. There's no canonical resolution.

[1]: https://toucanpost.com [2]: https://github.com/mackuba/didkit

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

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

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

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.

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

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!

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/

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/

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.

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!