Live data from Hacker News

New startup sells coffee through SSH

terminal.shop

231–240 of 430 posts

Re: New startup sells coffee through SSH

#231
post #5

Interesting. I like this. No need for a cookie banner.

There is never a good reason for cookie banners, by definition. The rule is that if you have a good reason for your cookies (i.e., basically one that isn't user-hostile), you have nothing to worry about and don't need a cookie banner. It's only when you engage in user-hostile practices, such as tracking, that you need to ask for consent. I'm being sightly snarky, but that's really the essence of it.

Very few people understand the law and just opt to defensively throw a cookie banner up on the site. Usually a 3rd party service.

At this point I’ve even had clients ask for it, thinking it makes their site more professional and credible, since everyone else does it.

Re: New startup sells coffee through SSH

#232

Earlier quoted context omitted.

That's baby+bathwater. Just use ssh-add -c to have the ssh-agent confirm every use of a key.

TIL. Thanks! Gonna do wonders when working at places where I can't use a hardware key with physical confirmation of use. My assessment still stands. Use proxyjump (-J) instead of proxy command whenever possible.

Whenever possible, yes, but AIUI it's not always possible; the one use case for which I believe full-on forwarding is required is using your personal credentials to transfer data between two remote servers (ex. rsync directly between servers). If there's a way to do that I would actually much appreciate somebody telling me, but I have looked and not found a way.

Re: New startup sells coffee through SSH

#233
post #40

One safety tip: disable SSH Agent Forwarding before you connect, otherwise the remote server can theoretically reuse your private key to establish new connections to GitHub.com or prod servers (though this host is unlikely malicious). https://www.clockwork.com/insights/ssh-agent-hijacking/ (SSH Agent Hijacking)

The full command you want is: ssh -a -i /dev/null terminal.shop to disable agent forwarding, as well as to not share your ssh public key with them, but that's just a little less slick than saying just: ssh terminal.shop to connect.

Honestly the only thing that you need is -a (and only if you made the bad choice to do agent forwarding by default). Sending your pubkey (and a signature, because the server pretends to accept your pubkey for some reason?) isn't a security risk and you're (in theory) going to be providing much more identifying information in the form of your CC...

(And as the siblings mentioned this won't work to prevent your key from being sent if you're using an agent)

Re: New startup sells coffee through SSH

#234

So unless you mean to exclusively sell coffee to users who don't have a white terminal background, you may want to consider your color scheme. I was missing the white text. (I know this is considered an atrocity by some, but I happen to not really care enough about my terminal color to change the default)

The atrocity was committed by whoever set that default, we can work out a plea deal as long as you rat them out.

Mac OS X’s Terminal.app used to be black-on-white by default, wouldn’t be surprised if that’s still the case.

Re: New startup sells coffee through SSH

#235
post #125
post #40

One safety tip: disable SSH Agent Forwarding before you connect, otherwise the remote server can theoretically reuse your private key to establish new connections to GitHub.com or prod servers (though this host is unlikely malicious). https://www.clockwork.com/insights/ssh-agent-hijacking/ (SSH Agent Hijacking)

Is it not standard practice to make different keys for different important services? I have a private key for my prod server, a private key for GitHub, and a private junk key for authenticating to misc stuff. I can discard any without affecting anything else that's important. If I authenticated with my junk key, would my other keys still be at risk?

The only reason/benefit for using different keys is to prevent someone from correlating your identity across different services... if you're worried about that go ham

Re: New startup sells coffee through SSH

#236
post #50

I'm curious how they built this. It's SSH but the IP address is Cloudflare's edge network. It could be using CF Tunnel to transparently route all the SSH sessions to some serving infrastructure, but I didn't know you could publicly serve arbitrary TCP ports like that. Building it in serverless fashion on CF Workers would be ideal for scalability, but those don't accept incoming TCP connections.

Yup! Cloudflare naturally advertises HTTP most heavily and it has fancier routing controls, but it supports arbitrary TCP protocols. > Cloudflare Tunnel can connect HTTP web servers, SSH servers, remote desktops, and other protocols safely to Cloudflare. https://developers.cloudflare.com/cloudflare-one/connections... > In addition to HTTP, cloudflared supports protocols like SSH, RDP, arbitrary TCP services, and Unix…

Cloudflare Tunnels only open HTTP/S to the internet, you'll need their client to reach the other protocols. More likely that this is Cloudflare Spectrum.

Re: New startup sells coffee through SSH

#237

I am very curious how this is built, I would like to build similar SSH interactive experiences. Any resources and how to get started would be really appreciated. (I know how to setup a basic TCP server that listens on SSH port, but I really don't know how to implement navigation etc for the SSH experience)

I think they use Wish in Go: https://github.com/charmbracelet/wish The company making this, charm.sh, has a whole bunch of cool cli frameworks

Re: New startup sells coffee through SSH

#238

PSA to anyone making a public SSH service: List the fingerprint, not the host key, thanks. (Or better yet list both!)

Please avoid acronyms on HN or spell them out. We don't all live in your context.

duckduckgo just says PSA is Prostate specific antigen. What did you mean?

Re: New startup sells coffee through SSH

#239
post #40

One safety tip: disable SSH Agent Forwarding before you connect, otherwise the remote server can theoretically reuse your private key to establish new connections to GitHub.com or prod servers (though this host is unlikely malicious). https://www.clockwork.com/insights/ssh-agent-hijacking/ (SSH Agent Hijacking)

That's terrifying. I don't understand why the design requires Forwarding to work without more explicit consent from the client at use time. (That is, when the middle tier wants to make a connection, it should forward an encrypted challenge from the server that can only be decrypted, answered, and re-encrypted by the original ssh keyholder on the client, similar to how, you know, ssh itself works over untrusted routers.
Post reply on HN