antoniomika

We added SSH certificates support to pico.sh [1] and it's been great. Utilizing principals gave us the ability to implement a RBAC like system for specific parts of the pico.sh ecosystem. Users get the flexibility they want with limited complexity.

[1] https://pico.sh/access-control#ssh-certificates

Currently, you can either provide the `BORG_REPO_PERMISSIONS` env var to borg [0] or `--permissions` flag to `borg serve` [1]. You can then enforce this as part of your `authorized_keys` command, for example.

[0] https://github.com/borgbackup/borg/blob/3cf8d7cf2f36246ded75...

[1] https://github.com/borgbackup/borg/blob/3cf8d7cf2f36246ded75...

This has been replaced with a permissions feature that still provides both delete and overwrite protections. The difference is the underlying store needs to implement it rather than running a server that understands the permission differences. You can read more about this change here: https://github.com/borgbackup/borg/issues/8823#issuecomment-...

Check out sysbox[0], it's a runc based runtime that allows you to run "system" containers without privilege.

[0] https://github.com/nestybox/sysbox

Yep! tuns would be the service you want since it can support forwarding arbitrary backends: https://pico.sh/tuns#custom-domains

We’re actually using Unix sockets as the underlying transport layer for this. We’re also not using sshd, we custom wrote our own daemon that’s entire job is tunneling. If you’re curious about this, you can find the project here: https://github.com/antoniomika/sish

sish was actually my first foray into SSH apps. It was a lot of fun to write and pretty much implements tunnels with a routing system on top. It manages connectivity, routing, and reverse proxying all within user space. No namespaces required!

tuns can actually even tunnel UDP traffic over SSH, also entirely in user space. Docs for that can be found here: https://pico.sh/tuns#udp-tunneling

We're actually fully open source and all development occurs in the open! Here's the repo https://github.com/picosh/pico and you can find us on Libera IRC

Hrm that's odd! Just tested and everything looks fine. Any logs or errors you can share?

Our host keys are published here and are durable: https://pico.sh/host-keys

Ashburn, VA and Nuremberg, DE!

Woops! Delete is supported, will update that as well

Correct! The tunnels are protected using ssh auth as well, so you can ensure that only the users you want to access it can.

I'd actually highly recommend taking a look at vaxis (https://github.com/rockorager/vaxis). We've moved away from wish/bubbletea and have really enjoyed working with vaxis!

Sorry, this is a focus issue with a tui which we'll fix up soon! Should just need to hit <tab> until OK is highlighted and then press enter

We recently changed our tui framework and the functionality for focus is a bit different. You might have to hit <tab> until `ADD` is highlighted. You can also rsync/scp/sftp an authorized_keys file and we'll add that to your account!

And we're still free! Just added some payments to help keep things running smoothly and allow us to invest in more infrastructure. pgs (static sites) and tuns (tunneling) are both multi-region for example.

And we'd be happy for you too! All of our code/tools are open source and available here: https://github.com/picosh/pico

Honestly never had a chance to merge it/review it. Once the company wound down, I had to move onto other things (find a new job, work on other priorities, etc) and lost access to be able to do anything with it after. I thought about forking it and modernizing it but never came to fruition.

I wrote a system that did this >5 years ago (luckily was able to open source it before the startup went under[0]). The bastion would record ssh sessions in asciicast v2 format and store those for later playback directly from a control panel. The main issue that still isn't solved by a solution like this is user management on the remote (ssh server) side. In a more recent implementation, integration with LDAP made the most sense and allows for separation of user and login credentials. A single integrated solution is likely the holy grail in this space.

[0] https://github.com/notion/bastion

Nope! I utilize env files for all of my password/privileged settings. In the command entry for docker-compose.yml, you can then use a non-templated env var (one that docker-compose itself doesn't fill) by replacing a single dollar sign with two. That then loads the credential from the environment instead of command line.

Thanks for the feedback and trying things out!

- We like the "ssh to create an account" idea too. Makes it easy to confirm a user's identity which is nice and uses tried and true auth/encryption methods. Feedback has been good overall for the experience, main issue is managing account reset methods as that is a bit difficult.

- Noted on the account signup UI, we'll look into how we can work on making that cleaner (a blinking cursor is probably a good start).

- Once you signup, you can actually ssh to pgs without any username set and it will find the account for the public key used on signup.

- The site URL is a bit hard to deal with when uploading multiple files. We'll think of how to make this more clear.

- There's a "cli" based workflow with pgs. You can list your sites with `ssh pgs.sh ls`, you can replace `ls` with `help` for a list of other commands. We want to move away from the TUI a bit and have commands that are easy to be scripted.

- $20/year :)

Thanks again for all of the feedback, always appreciated!

We do use Caddy, but just for reverse proxying and handing TLS. We utilize custom http/ssh servers on the backend to handle everything. All of our work is open source and we do development in the open / discuss features over IRC on Libera. You could self host pgs if you wanted! Here's the repo: https://github.com/picosh/pico

Most of the services we've developed at https://pico.sh are more-so geared to "power users". It was difficult to quantify that in a single word so hackers is where we landed. Being users of HN ourselves, it felt like the right term but any pico.sh service is open to anyone!

Thanks for the feedback! This should definitely be supported so we'll get on fixing that!

We don't presently have webhooks, but do have a GitHub action for this (https://github.com/marketplace/actions/pgs-action). The goal was to make it easy to deploy using off the shelf tools and not require anything to be installed for usage. I could see us thinking about making this a feature/addon down the road.

We have rsync implemented with our other pico services, but we need to spend some time to finish implementing the rest of the protocol (support proper diff/upload, this includes recursive file uploads). We'll have that implemented once we're ready to open this up to everyone else. Of course, contributions to help get it over the line are always appreciated :)

Thanks for posting! I’d suggest this to anyone that wants a stateless setup method which uses standard SSH key/password auth. sish also has support for internal tunnels (hidden from the world and accessible with local/remote SSH forwards), SNI tunnels (zero trust TLS tunnels), TCP, and of course HTTP(S)/WS. Also does request inspection ala actual ngrok :)

Disclaimer: I’m the author and have done tunneling for years

Added benefit is sish handles all of the hostname/certificate provisioning on its own and does things like internal tunnels, TCP tunnels, and gives you a little website debugging tool as well. All in a single binary :)

Disclaimer: I'm the author of sish

Now that's one I never knew about. I'll have to take a look, should be easy enough to update prose to handle that though.

edit: Updated prose to handle this

Yep you’re right! My example was done with a CNAME on a subdomain (replaced the domain for privacy), and most providers provide flattening so I didn’t even think about it! I’ll update the copy to mention that.