New startup sells coffee through SSH
terminal.shopOne 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:
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 -a -i /dev/null terminal.shop
to connect.ssh terminal.shopI'm curious why you added `-i /dev/null`. IIUC, this doesn't remove ssh-agent keys.
If you want to make sure no keys are offered, you'd want:
I'm not sure if the `-i` actually prevents anything, I believe things other than /dev/null will still be tried in sequence.ssh -a -o IdentitiesOnly=yes terminal. ShopCheck for yourself with
vsssh -v -i /dev/null terminal.shop
What you're looking for is that there is no line that says something likessh -v terminal.shop
Upon further testing, the full command you want is:debug1: Offering public key: /Users/fragmede/.ssh/id_rsa RSA SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
to forcibly disable a local identity agent from offering up its identities as well, and not just agent forwarding.ssh -a -i /dev/null -o IdentityAgent=/dev/null terminal.shopUpon further testing,
still offers up my public key on my system (macOS, OpenSSH_9.6p1, LibreSSL 3.3.6), contrary to what StackOverflow and the Internet seems to think. Tested by hitting whoami.filippo.io, linked in child comment.ssh -o IdentitiesOnly=yes terminal.shopAha, yes, `-o IdentityAgent=/dev/null` is better for my intent. I was confused that `-i` wasn't removing .ssh/id_rsa from the candidates, but that was ssh-agent.
That looks pretty solid. Thanks!ssh -a -i /dev/null -o IdentityAgent=/dev/null terminal.shopFor a cool example (deanonymization), see https://words.filippo.io/dispatches/whoami-updated/ (discussed at time: https://news.ycombinator.com/item?id=34301768). Someone has crawled public keys from GitHub (tbh I was surprised that GitHub publishes them) and set up a database.
It's quite useful! I can give someone access to my server by grabbing their public key and creating an account for them, no need figure out how to send them the password to my server.
That's indeed how public keys are intended to work.
It's one of those obvious in hindsight things that gives me that "Internet was not a mistake" feels.
Gitlab does the same.
I've seen provisioning scripts and even cloud-init if I'm not wrong supporting downloading keys in that manner.
From one side it's cool from other side allows to bypass of system administrator for keys update more easily.
> You can make a search for all users, which will tell you there are 97,616,627 users at the time of this writing, but you can only fetch at most 1000 results from a search, and they don’t come in any clear order, so you can’t just make the next search start where the previous one left off (or I didn’t figure out how).
> What you can do though is request accounts created in a certain time range. If you get the time range right, so that it has less than 1000 entries, you can paginate through it, and then request the next time range.
This reminds me of when I tried to add a google drive storage backend to camlistore/perkeep (because I had nearly-unlimited free quota at the time). One of the things a perkeep blobserver needs to be able to do enumerate all the blobs it has, in order. You can send millions of blobs to google drive without issue, but you can't directly paginate a search for them in sorted order.
You could just issue a search for all blobs under your perkeep drive folder, keep paginating the result until you run out of pages, and then sort in memory, but there's really no way of knowing how many blobs you're going to end up with and you might blow out your blobserver's memory.
Perkeep blobs are identified by blobrefs, SHA sums of the contents of the blob, so they look like sha-[0-9a-f]{64}. Google drive lets you search for files with a name prefix, so you can search for like /perkeep/sha-* and see if the result has a pagination token (indicating that there are more than 1000 results), and if so then you search for each of /perkeep/sha-0*, /perkeep/sha-1*, ... , /perkeep/sha-f*, each time checking to see whether there are too many matches. When there's not too many matches, you've found the prefix length that will let you fetch a bounded number of blobrefs, emit them to the perkeep client, and then release the memory before fetching more.
I didn't end up landing the patch before I lost interest, partly because it was pretty much the first golang I had tried writing. It was fun working out the above details, though./pk/sha-\* 1000+ results (non-empty pagination token) /pk/sha-0\* 1000+ results (non-empty pagination token) /pk/sha-00\* 1000+ results (non-empty pagination token) /pk/sha-000\* 193 results, sort these in memory and emit to client /pk/sha-001\* 179 results, sort these in memory and emit to client ... /pk/sha-fff\* 223 results, sort these in memory and emit to client> I tried to add a google drive storage backend to camlistore/perkeep (because I had nearly-unlimited free quota at the time)
This explains the quotas now :)
Offering your public key only allows them to identify the key and prove you have it. There is no security concern in sending this to an untrusted server.
Agent forwarding is a whole other beast.
Hm I thought I'd edited this. I was mistaken,
works as expected, however I had an IdentityAgent set, and my key was being submitted via that route.ssh -o IdentitiesOnly=yes terminal.shop
behaves as expected; same asssh -o IdentitiesOnly=yes -o IdentityAgent=/dev/null terminal.shop
Verified via whoami.filippo.io.ssh -a -i /dev/null -o IdentityAgent=/dev/null terminal.shop
instructions not clear, my entire drive is empty now
1. Why is this something that would be enabled by default.
2. Can't you disable agent forwarding in a config file, so as not to have to clutter the command line?
I think it’s disabled by default on all distros I’ve used. You could add an entry to /etc/ssh_config or ~/.ssh/ if you want.
(It’ll still offer public keys by default in the exchange, but that’s “just” a privacy issue, not a privilege escalation problem.)
I just ran it in a `tmpfs` without any credentials:
$ bwrap --dev-bind / / --tmpfs ~ ssh terminal.shopI think you may want to clear the environment (e.g., of `SSH_AUTH_SOCK`) as well as isolate in a PID namespace as well. I also reflexively `--as-pid-1 --die-with-parent`.
(The `bwrap` manpage says “you are unlikely to use it directly from the commandline,” yet I use it like this all the time. If you do, too, then we should be friends!)bwrap --dev-bind / / --clearenv --tmpfs ~ --unshare-pid --as-pid-1 --die-with-parent ssh terminal.shop
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)
I agree with you, but there are those that take an extreme stance on privacy and I'm willing to oblige.
SSH Agent Forwarding does not happen by default. You need to include the -A option in your ssh command, unless maybe you've enabled it globally in your ~/.ssh/config file.
They can't get your private keys, but they could "perform operations on the keys that enable them to authenticate using the identities loaded into the agent" (quoting the man page). This would also only be possible while you are connected.
This is only a threat if you enable agent forwarding for all hosts.
If you enable agent forwarding for all hosts then yes, data will be forwarded.
Your link says:
> Don’t enable agent forwarding when connecting to untrustworthy hosts. Fortunately, the ~/.ssh/config syntax makes this fairly simple
Like you noted, ForwardAgent no is the default in /etc/ssh/ssh_config.
*disable ssh agent FORWARDING.
Which honestly should always be disabled. There are no trusted hosts.
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.
What can also help is specifying the right options right in ~/.ssh/config for certain hosts and domains: E.g. do "ForwardAgent no" globally, use a "Match *.my-trustworthy-company-domain.com" block and add "ForwardAgent yes" there.
Also very good for other options that are useful but problematic when used with untrustworthy target hosts, like ForwardX11, GSSAPIAuthentication, weaker *Algorithms (e.g. for those old Cisco boxes with no updates and similar crap).
Another neat trick is just using a ""Match *.my-trustworthy-company-domain.com" block" with an "IdentityFile ~/.ssh/secret-company-internal-key" directive. That key will then be used for those company-internal things, but not for any others, if you don't add it to the agent.
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.
Or use a hardware backed ssh key you have to tap once for every use, like a Yubikey or Nitrokey.
Default for the last 24 years according to https://github.com/openssh/openssh-portable/blame/385ecb31e1...
I've found myself to be much more comfortable to just define all my private keys in ~/.ssh/config on a host-by-host basis.
AFAIK, this doesn't solve the SSH agent problem - the problem is the agent has access to all of those keys regardless of the host you connect to.
So forwarding your SSH agent means an administrator of the system you're connected to could use any of those host keys loaded in the agent to connect to their associated machine.
> There are no trusted hosts.
...your own (headless) server that's in the same room as you, when you're using your laptop as a thin-client for it?
Depending on what it's serving, and how up to date it is, and who else is on that network and can access the server, and who else can come into that same room when you're not there, and from where you get the software that you install on that server... it might be less trustworthy than you think.
But if that's your standard then the laptop you're connecting from is not trusted either, and then you're not even allowed to use your own keys.
You're allowed to draw sensible boundaries.
With all these recent exploits, I wouldn't even be 100% sure of that.
But if I can't trust even that host, I also can't trust the host I'm working on and which doesn't need agent forwarding to access my SSH agent.
Trusting one host is safer than trusting two hosts.
This is where certs are nice, sign one every morning with a 8/12 hour TTL
Interesting idea. Does need some automation though to make it practical irl.
Just to be clear, ssh agent forwarding is disabled by default and enabling it is always a hazard when connecting to machines that others also have access to.
Not at all specific to this.
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?
> If I authenticated with my junk key, would my other keys still be at risk?
Yes, if you authenticate with your junk key (or no key), and SSH agent forwarding is enabled, you are still at risk. It lets the remote machine login to any server with any keys that are on your local SSH agent. Parent's link shows how this can be abused.
Fortunately, it's disabled by default, at least on newer versions.
It's a good practice, but it's somewhat against the grain of ssh defaults. It's not surprising that many people stick to the defaults.
It’s a practice, but not necessarily a standard one. In any case if even one person sees that, the advice will have served its purpose.
TIL, the good news I guess is I only ssh into my hosting platforms and GitHub who have a reason to protect my data since I pay them.
Still I'll be sure to break up my keys more going forward and disable SSH forwarding.
disabling agent forwarding is the important bit.
But if you do want to break up your keys more, make sure you specify IdentityFile and Identities Only in the per host definitions in your ssh config.
By default assuming you use an ssh agent (no forwarding) with multiple keys and a default ssh config, the behavior is to just try to auth with every key in order.
So if you're worried about the ssh server identifying you, you're still exposing yourself. I don't think this is much of a concern but worth noting.
Slightly more important: you're wasting time during the initial connection to fail authentication a few times. This can matter more with higher latency
Even more important: sshd has a configurable number of times a client is allowed to fail authentication in a session attempt. If you have too many other keys in your agent you will just fail to auth before it tries the key that is actually valid for that host.
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
If anything it's more standard practice to have agent forwarding disabled, since that's the default.
Default is disabled.
Exactly, this tip only applies if you reconfigured ssh to automatically forward agent to all hosts, which is absolutely insane.
I take it you mean disable ssh agent forwarding — the agent itself is fine. You should never forward your ssh agent to a box you don’t trust as much as your own.
Message edited, thank you, you are absolutely right.
And for privacy, don’t let it know your identity or username:
Otherwise, the remote server can probably identify who you are on platforms like GitHub.ssh -o PubkeyAuthentication=no -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -a nobody@terminal.shopWhat I am reading from this there be dragons so don't use SSH to buy coffee!
I think so.
This feature is not enabled by default; "ForwardAgent = yes" has to be in the config file.
The article you cited makes it clear that you can turn this on for specific hosts in your private SSH config (and probably should do it that way).
So why wouldn't you?
Turning on forwarding globally and then having to remember to disable it for some untrusted hosts with -a looks silly and error-prone to me.
"ForwardAgent no" in ~/.ssh/config will do this automatically.
Not having "ForwardAgent yes" in ~/.ssh/config will do this automatically too.
Seems like a ridiculous amount of hoopla over something that isn't even a default.
Is "Host * \n AddKeysToAgent yes" acceptable from a security POV or should that also be per host?
Is it "yes" by default? If so, that seems insane given what the op said about it. But other comments say it's "no" by default. If it's "no" by default, why are people alarming us by bringing this up? And why for terminal.shop in particular?
The man page for ssh_config(5) says that it is set to "no" by default, at least on my computer.
Maybe there was some blanket advice in the past to enable it? Idk, this got me alarmed for nothing.
It's off by default. No idea what this fuzz is about. Gathering internet attention points maybe?
Using discoverable and non-discoverable keys via FIDO security keys will require PIN + physical confirmation, or just physical confirmation, by default if anyone tries to use your agent's keys.
If you want to use SSH forwarding reasonably safely, use a yubikey for ssh so you have to tap once for each hop. Now a MITM can't use your key for more hops without you physically consenting to each one.
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.
AFAIK, that’s exactly how agent forwarding works. The explicit part is that you need to explicitly turn it on
It is not the default, you would have to have a silly config for this to matter.
You can configure the agent to confirm each key usage to have your cake and eat it too. :)
It's also good to see if any malicious process tries to make use of the agent locally!
Thanks for the PSA. It gave me a good opportunity to double check that I hadn't enabled agent forwarding in any of my SSH scripts that don't need it.
You actually want to verify first or someone will mitm you, e.g. mitm.terminal.shop.rag.pub
With this one comment, you’ve convinced me that ssh apps are a bad idea
i usually just disable ssh agent forwarding globally by default, and only enable it selectively via my ~/.ssh/config
Dang. Didn't know this was a thing. Thank you!
here we go again. domain and path restricted cookies anyone?
I can't test this due to the product being out of stock, but I wonder what their approach to PCI compliance is.
Processing credit card data has a high compliance burden if you're unwilling to use a secure widget made by an already-authorized provider like Stripe. That's for a good reason, most web and mobile apps are designed such that their backend servers never see your full credit card number and CVV. You can't do this over SSH.
I also wonder whether you could even do this if you had to handle PSD2 2-factor authentication (AKA 3d Secure), which is a requirement for all EU-based companies. This is usually implemented by displaying an embed from your bank inside an iframe. The embed usually asks you to authenticate in your banking app or enter a code that you get via SMS.
You can take the easy way out of course and make the payment form a web page and direct the user to it with an URL and/or a Unicode-art rendition of a QR code.
They mention in the faq that they use Stripe - https://www.terminal.shop/faq. Stripe does offer integrations that are not natively using their widgets. Ultimately, the PII data is stored at Stripe.
PS: I work at Stripe but I don't really work on the PCI compliant part of the company.
The fact that the card number data is stored at Stripe doesn't matter that much. As parent commenter says, the card numbers are still visible on terminal.shop's network because it all goes over their SSH connection.
For most websites that use the Stripe widget, the website owner can never see the full card number, because the credit card number entry fields are iframed in on the page. That means website owners in this scenario are PCI compliant just by filling out PCI SAQ A (self assessment questionnaire A), which is for "Card-not-present Merchants, All Cardholder Data Functions Fully Outsourced": https://listings.pcisecuritystandards.org/documents/SAQ_A_v3...
But that questionnaire is only for merchants where "Your company does not electronically store, process, or transmit any cardholder data on your systems or premises, but relies entirely on a third party(s) to handle all these functions;" For e-commerce merchants who CAN see the card number, they need to use SAQ D, https://listings.pcisecuritystandards.org/documents/SAQ_D_v3.... This includes additional requirements and I believe stuff like a pen test to be PCI compliant.
it's been a while since I did the full pci compliance rigamarole, but I don't recall it being that difficult. you basically just answer a bunch of questions correctly about how you are transmitting and storing the data using sufficient encryption and then they run some automated pen tests on your site and then you are done.
>run some automated pen tests on your site and then you are done
Haha you are obviously choosing to hide some pain away from your memories.
I agree that you run automated pen tests, but then securing up all networks servers with the results of those pentests can be incredibly time consuming and awkward.
I suppose on a very complex system, that could be a big deal. But I think the last site I did it on was running on AWS so all ports were closed unless I specifically opened them for a specific purpose and it was just a few tweaks I had to make to pass. I normally only have 80 and 443 open to the outside world.
It's expensive.
you can say the same about the widget, as the website embedding the widget has access to the document's keydown
If the widget is in an iframe with a different host the parent documents JS engine has no way of interacting with the child.
The parent documents JS engine can replace the iframe with their own that looks the same
To be clear, that is exactly what the PCI SAQ A-EP questionnaire covers. It basically says "You don't access any cardholder data, but you own the page that hosts/redirects to the third party processor (like Stripe)." So the questions in the SAQ A-EP are about ensuring that your page has enough basic security (at least as can be asked in a questionnaire) to prevent hijacking, whereby a nefarious script (through an XSS vulnerability for example) sends them to a site to phish their cc details. Note that a decent content security policy on your website can prevent most of these types of problems.
That wouldn't help, at least with my bank in the UK, the iframe just shows a message to open the mobile app to approve the payment. The payment details are then shown in the app, you don't interact with the page in the iframe at all.
But that would still require an eagle-eyed consumer, which (coming from experience working in the fintech space) is quite rare.. I.e., you may know the iframe is supposed to just ask you to open your mobile app, but I think the vast, vast majority of users wouldn't think twice if that iframe had been hijacked and instead asked them to enter their credit card information directly.
Interestingly Stripe started life as /dev/payments and I seem to remember the first iteration was an agent on your server that literally processed card payments when you wrote the details to /dev/payments
That's awesome
You can still find the source code here: https://github.com/benweissmann/dev-payments
I'm guessing they ditched that idea because it wouldn't absolve the "writer" of PCI compliance, since the information has to pass through RAM.
I thought /dev/payments was their second name. Weren't they /dev/creditcard or something like that first?
Not just EU companies. Also EU customers. I cannot use my cards in a Card-Not-Present transaction that does not support 3D Secure. This obviously isn't a concern for them yet since they only ship to the US, but it might become one.
In the past one of my banks required me to put in a One-Time Password on the frame I'm shown. While it's different right now, you do need to show that page in the general case. That would really break the immersion of their process :/
I remember seeing a 3D Secure screen in some app that didn't use a webview but rendered the form as native controls. It worked with Estonian LHV at least (I think?). If that can be done with Stripe, they could render the form as a TUI.
And if everything fails, they can just render the 3DS page in the terminal! (e. g. using Browsh [1]) Although I'm not sure if that would be compliant with the regulations.
Another option is Carbonyl browser.
I think that a better way (which is protocol-independent, and does not require a web browser, or even necessarily an internet connection), would be a kind of payment specification which is placed inside of a order file. This payment specification is encrypted and digitally signed and can be processed by the bank or credit card company or whatever is appropriate; it includes the sender and recipient, as well as the amount of money to be transferred (so that they cannot steal additional money), and possibly a hash of the order form. A payment may also be made by payphones or by prepaid phone cards (even if you do not have a bank account nor a credit card), in which case you may be given a temporary single-use key which can be used with this payment specification data; if you do not do this, then you can use the credit card instead.
I was asking myself the same thing while watching the live stream where they somehat explained how it works.
It's still not clear to me if they are compliant.
To make it work like in the browser it would require some sort of SSH multiplexing where your client is connected to both the shop and Stripe's SSH server and you enter your card data into a terminal region that is being rendered by stripe's ssh server. And then the triangle is completed by Stripe notifying the shop that the payment is ok.
Wouldn’t it be amazing if there was a simpler way to pay money online.
I don't know if this is sarcasm or not, but in Poland we have BLIK and it is amazing. Paying online is as simple as entering a 6 digit code from the app and confirming transaction in the app. Afaik every major bank supports it too
I would prefer if these systems worked internationally and didn’t exclude foreigners.
But yea…
There are: Ria, Revolut, Wise, Skrill, TransferGo etc.
The websites faq says they are still using stripe for payment and ordering - however this may work.
The FAQ says they use Stripe for orders and don't even have their own DB in which to store purchase data, so PCI compliance should be a non-issue
PCI compliance is never a non-issue.
Even if you're using a third party provider that handles both credit card entry and processing, you need to comply with some subset of the PCI/DSS requirements.
In the case of terminal.shop it's not even true, since they can see the credit card number on their side, even if all they do is to forward that number to Stripe and forget about it.
For small and medium-sized merchants, PCI/DSS classifies different types of handling through the concept of which SAQ (Self-Assessment Questionnaire) you have to fill in. Different SAQ have different subset of requirements that you need to fulfill. For e-commerce use cases, there are generally 3 relevant SAQs, in order of strictness:
- SAQ A: Applicable when the merchant redirects payment requests to the payment processor's page or shows an iframe that is hosted by the processor. This is the level required for Stripe Checkout or Stripe Elements.
- SAQ A-EP: Applicable when the merchant handles input on the browser, but sends the data directly to the processor without letting it pass through the merchant's server. This is equivalent to the classic Stripe.js.
- SAQ D: Applicable when the card data is transmitted, stored or processed on the merchant's own server, even if the merchant just receives the card number and passes that on to the payment provider. Stripe calls this type of usage "Direct API Integration" [1].
The level of compliance required for terminal.shop should be SAQ-D for Merchants, which is quite onerous. It covers almost all of the full set of PCI/DSS requirements.
But even if a merchant just uses Stripe.js, the PCI SSC still cares about the possibility of an attacker siphoning card data from the merchant's site through an XSS vulnerability.
And even if the merchant is using an iframe or a redirect (with something like Stripe Checkout or Stripe Elements) there is still the possibility of hard-to-detect phishing, where an attacker could replace the iframe or redirect target with their own site, made to look exactly like Stripe.
---
I think the important element is that terminal.shop's use case (likely SAQ D, likely level 4 or level 3 volumes) allows them to comply with relatively minimal expense and complexity.
Sure, there would be a non-zero time investment required to implement and ensure actual compliance with what is being attested, but it's quite doable for a person or small group of folks with a mix of SDE skills, SRE-like skills, and PCI-DSS experience.
One esy to solve this is to use a terminal web browser like Carbonyl.
The burden of PCI compliance is a lot lighter than you might think. You basically just have to fill out a bunch of forms, there's no inspection or anything.
You obviously havent had to manage PCI compliance for a company which takes credit card numbers directly onto their site or over the phone.
No I'm not a manager, I'm a programmer. I haven't personally had to fill out the forms, we have a guy for that. Actually that's not his main job, but he used to work as a paralegal so he got volunteered for it.
A lot of people don't know that before Amazon started, there was a company out of Portland, OR called Bookstacks selling books via a telnet interface. In the early days, Bezos was quite worried about their potential to get "there" first (wherever "there" was going to be). It was a fairly cool interface, at least for 1994.
[ EDIT: worried to the point that we actually implemented a telnet version of the store in parallel with the http/html one for a few months before abandoning it ]
There were a few using telnet before the web gained wider traction. For example, CDNow started out that way in 1994.
I remember ordering a CD via CDNow and a very rudimentary SMS interface on my phone around 1996. It took about 10 minutes to go through the entire process, but I did it while at the movies with my wife, waiting for the previews to start and we both thought it was just SO advanced.
That is an epically cool story from the early days of the Internet / web. Thanks for sharing!
A brief reminder that SMS has nothing to do with the internet (TCP/IP) or the web (HTTP).
Netflix also was founded in 2007, not 1997.
I bought a CD from CDNOW over Telnet in the early 90's!
I also remember telnet BBS's became popular for a few years when I was in college 91-93.
That's how I ordered my first CDs online: via a Telnet interface. It sounds crazy 30 years later.
Yes, they were the original books.com, and I used to buy from them via telnet before they had their www site up.
Do you have more info? I found this article[0] about "Book Stacks" which became Books.com, but it looks like they were based in Cleveland?
[0] https://sbnonline.com/article/visionary-in-obscurity-charles...
More info is: I was wrong, Ohio is right.
Yes, books.com was based in Ohio. I bought from them via the mentioned telnet interface.
> selling books via a telnet interface.
Were people just that trusting back then, or had they figured out some kind of pre-SSL way of securing things?
In terms of MITM attacks, yes, they were trusting
Even back in 2010 lots of sites were http, like Facebook, & there was FireSheep which would snoop on public wifi for people logging into sites over HTTP
In 1994? Most of the internet was unencrypted, and it wasn't very commercial yet. https had just been invented, and ssh was a year away. There was no wifi, everything was dial-up unless you were at a university or something, and snooping just wasn't all that big a risk.
I can only talk from personal experience I did not trust most online payments around the turn of the millennium, but I did order quite a few things online. I usually payed either by collect on delivery or by invoice like regular good old fashioned mail-order, or by the early 00s VISA had something called e-card or similar, where you could generate a temporary one time use CC via a Java applet, this card was only valid for a day and could only be charged by a pre-determined amount, making the risk very low.
We were aware of this in the earliest days of amzn, and included a phone-in payment option to try to deal with this reluctance. It was rarely, rarely used.
A large bookstore was using CLI for their internal inventory management system well into the 2000s.
amzn was likely doing that too. the original tools that we wrote in 94-96 for store ops were all CLI.
hey! i'm one of the people who worked on this, we actually launched a few days ago and sold out quite quickly - we'll remove the email capture so you can poke around
we'll be back in a few weeks with proper inventory and fulfillment
we'll also be opensourcing the project and i can answer any questions people have about this
Oh wow. You’re the guy who knows Adam right? His Laravel video was so inspiring.
oh shit, you're open sourcing this as well? I'd love to use a similar workflow for some of my projects. Love the idea!
Also you guys should post over on Threads -- a bunch of people over there are really into the idea as well: https://www.threads.net/@mockapapella/post/C5_vLdDP0J1
We're doing similar things over at https://pico.sh/
Hey, nice work, how to get updates about the open source release ?
probably follow the twitter account @terminaldotshop
"Strong keys, Strong coffee" There, you're welcome. :)
Is it /usr/locally grown and single .'ed? How quickly can they mv it to my ~?
as per chatgpt
This joke is a clever play on words that merges elements of computer programming and coffee culture. Let's break it down:
New startup sells coffee through SSH: SSH stands for Secure Shell, which is a network protocol that allows for secure communication between two computers. In this context, the joke suggests that this new startup is selling coffee through a secure connection, presumably online. Is it /usr/locally grown and single .'ed?: This part of the joke is a play on the directory structure in Unix-like operating systems, where /usr typically contains user-related programs and data. "Locally grown" suggests that the coffee is sourced locally, and "single .'ed" is a wordplay on "single origin," a term used in coffee culture to denote coffee that comes from a single geographic origin. The /usr/locally grown part humorously combines Unix directory structure with the concept of coffee sourcing. How quickly can they mv it to my ~?: Here, "mv" is a command in Unix systems used to move files or directories, and "~" represents the user's home directory. So, "mv it to my ~" is a playful way of asking how quickly they can deliver the coffee to the customer's home. It's also a pun on the idea of moving the coffee to the user's home directory.Pretty good
unzip
alias grind='gzip' alias coarse='gzip --fast' alias fine='gzip --best'
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 sockets.
https://developers.cloudflare.com/cloudflare-one/connections...
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.
I don't think that's correct. I serve matrix on 8443 through a tunnel.
Matrix is based on HTTP...?
Cloudflare supports 2052, 2053, 2082, 2083, 2086, 2087, 2095, 2096, 443, 80, 8080, 8443, 8880 for HTTP/S https://developers.cloudflare.com/fundamentals/reference/net...
True. You did not say "standard http port", thank you for clarifying.
That requires the client to install custom tunnelling software.
If you want the client to not require special software, they provide a web based terminal emulator for ssh, and a web based VNC client.
hey - worked on this it's using Cloudflare Spectrum which can proxy any tcp traffic
will be talking more about this soon
Some protocols do not support virtual hosting; apparently this includes SSH.
It would be possible to support other protocols with a single IP address (either because they are running on the same computer, or for any other reason) if they support virtual hosting.
Of the "small web" protocols: Gopher and Nex do not support virtual hosting; Gemini, Spartan, and Scorpion do support virtual hosting. (Note that Scorpion protocol also has a type I request for interactive use.)
NNTP does not support virtual hosting although depending on what you are doing, it might not be necessary, although all of the newsgroups will always be available regardless of what host name you use (which requires that distinct newsgroups do not have the same names). This is also true of IRC and SMTP.
However, if you are connecting with TLS then it is possible to use SNI to specify the host name, even if the underlying protocol does not implement it.
(This will be possible without the client requiring special software, if the protocol is one that supports virtual hosting. There may be others that I have not mentioned above, too.)
Most likely using "Spectrum" which allows Layer 4 TCP+UDP proxying/DDoS protection: https://www.cloudflare.com/application-services/products/clo...
Cloudflare workers has support for inbound TCP coming 'soon' [1]. Maybe they have early access?
[1]: https://developers.cloudflare.com/workers/reference/protocol...
┌──────────┬────────┬─────────┬───────┬────────────────────┐
│ terminal │ s shop │ a about │ f faq │ c checkout $ 0 [0] │
└──────────┴────────┴─────────┴───────┴────────────────────┘
nil blend coffee
whole bean | medium roast | 12oz
$25
Dive into the rich taste of Nil, our delicious semi-sweet
coffee with notes of chocolate, peanut butter, and a hint
of fig. Born in the lush expanses of Fazenda Rainha, a
280-hectare coffee kingdom nestled in Brazil's Vale da
Grama. This isn't just any land; it's a legendary
volcanic valley, perfectly poised on the mystical borders
between São Paulo State and Minas Gerais. On the edge of
the Mogiana realm, Fazenda Rainha reigns supreme, a true
coffee royalty crafting your next unforgettable cup.
sold out!
────────────────────────────────────────────────────────────
+ add item - remove item c checkout ctrl+c exitthis needs some "charm" to it. it's a bit basic
I long for an alternate dimension where terminal-based internet like Minitel dominated .
Something like hypercard implemented with 80x24 ncurses UI
ELisp and Emacs UI tools under the TTY version it's close.
Also, check gopher and gopher://magical.fish under Lynx or Sacc. The news section it's pretty huge for what you can get with very, very little bandwidth.
gopher://midnight.pub and gopher:/sdf.org are fun too.
And, OFC, the tilde/pubnix concept. SDF it's awesome.
I love TUI (as in text-based user interfaces) so much more than GUI. It always felt like a far more peaceful and productive environment.
I love the idea of TUIs, but I honestly don't have a lot of experience with them. There's a lovely Go library called Wish that I keep looking for reasons to use. https://github.com/charmbracelet/wish
charm bracelet has some really great projects and my obsession for TUI interfaces is why I'm learning Go so that I can use one of their libraries in a peoject
Responsive, high-contrast, low bitrate, low complexity
As long as I have ctrl+c/v copy and pasting I'm right there with you.
For DOS TUI, the standard was https://en.wikipedia.org/wiki/IBM_Common_User_Access: Shift+Delete to cut, Ctrl+Insert to copy, Shift+Insert to paste. These worked in DOS utilities like EDIT.COM, QBASIC.EXE and HELP.EXE, in all Turbo Vision apps including Borland Pascal and Borland C++ IDEs, in Visual Basic and Visual FoxPro for DOS, and they still work today in any Windows app that doesn't try to play silly tricks with its UI by doing its own text input.
Thanks for posting the link.
Shift+Insert has worked for decades in the XTerms I've used. It's bound in my muscle memory and is a source of frustration, for me, when attempting to use non-X Widows GUIs or odd-ball "terminals"/programs/foo.
don't you mean yy and p?
I think you mean M-w and C-y.
this comment is based
vim-based
vim-enhanced
vi-improved
The real power of the internet all along in my opinion was networked databases. Everything else is fluff and not a particularly great use of resources.
networked spreadsheets would have been ideal
Command line dominates in quick flexibility. But is awful when it comes to discoverability. Most people can't even find the turn off ads button in windows 11. And people hate that. So what hope do they have at a terminal.
I think Ms Dos 6ish TUI integration was very well done, better than Linux today.
Word perfect had good mouse support, as did Editor.
I have a theory that TUI is masculine and GUI is feminine.
To be fair, would the button isn't hidden away too badly, most people have no reason to go into settings for anything. They go through the wizard at the beginning (if that) to do first-time setup, then when they decide they don't like something they just deal with it or complain incessantly until someone fixes it for them.
Someone complained to me a while back about the size of icons on the windows desktop being too small - I told them they can hold Ctrl and scroll the mouse wheel to change the zoom level. They've complained about the same thing a couple times since, and so far as I can tell have made no effort to fix it.
Talking to people, settings terrifies them.
"Most people can't even find the turn off ads button in windows 11"
Perhaps the problem there is incentives.
ncurses!
TurboVision!
> # use the command below to order your delicious 12oz bag of Nil Blend coffee
> ssh terminal.shop
Oops, I thought I was supposed to enter it directly into the prompt on the webpage. The styling makes it look like an interactive console, I figured they included an embedded javascript SSH client for users who might not have one.
Made the same mistake
Reminded me of Hacker Scripts, specifically `fucking-coffee`:
> this one waits exactly 17 seconds (!), then opens a telnet session to our coffee-machine (we had no frikin idea the coffee machine is on the network, runs linux and has a TCP socket up and running) and sends something like `sys brew`. Turns out this thing starts brewing a mid-sized half-caf latte and waits another 24 (!) seconds before pouring it into a cup. The timing is exactly how long it takes to walk to the machine from the dudes desk.
Before a bunch of you run off and make more of these “because it’s cool”, they’ll likely lose access to stripe once stripes security team pay attention and realize that this can be trivially man in the middled and doesn’t actually offer the equivalent protection to https.
I wrote up a little demo and explainer at
https://mitm.terminal.shop.rag.pub
ssh mitm.terminal.shop.rag.pub> I wrote up a little demo and explainer at
They give you the ed25519 host key to insert into your known_hosts file on their homepage, which itself is served over TLS with all of the protections you describe in your article. They could go into more detail on being careful with not falling into the tofu trap perhaps, but I don't see that there's an inherent PCI-critical problem here. ssh tells you who, cryptographically, you're connecting to.
If I mess with my DNS and point it at your "little demo", this happens:
Anyone ignoring a big scary warning like that probably isn't going to brew the coffee properly anyway.$ ssh foo@terminal.shop @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!And guess what? My browser lets me bypass HTTPS warnings too! Yes, even when HSTS is enabled I can take steps to bypass the warning.
Except in their marketing materials they just say `ssh terminal.shop`
Users will fall into the TOFU trap, most users who've sent them cash certainly did.
Most users won't put their credit card credentials into a page that they've had to bypass a cert warning on.
Hmm, I'm having trouble finding that site. Sick sunset at rag.pub though!
It’s available via ssh and https
That shots from my parents balcony in Bermuda
PSA to anyone making a public SSH service: List the fingerprint, not the host key, thanks. (Or better yet list both!)
or better yet, don't use ssh for this purpose, it's not good for it.
letsencrypt is free, you might hate the browser for many fair reasons, but PKI and the CA/B forum are actually effective.
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?
I would blame this one on DDG, actually. PSA is an incredibly common acronym for public service announcement. Wherever DDG sources acronyms for might also be assuming people just know it. Try wiktionary or Wikipedia disambiguation pages for acronyms when they don't show up in search, I can often find them there.
What's HN?
IIRC Public service announcement.
Public service announcement. It’s very widely used
Sorry, I meant Secure SHell. Oh wait, that wasn't the widely-known acronym you asked about.
Sorry to see this downvoted, I think it's a common courtesy to spell out acronyms on first use, no matter how widely understood one believes them to be.
I think that's because most people consider this requires unjustified. Do you think similarly about expanding acronyms like SSH, CLI, HTTP, HN, FYI, USD, US, EU, PKI? Why/why not?
public service announcement, chatgpt would have got it for you
Hmm, a CLI interface for consumer purchasing.
Can I pipe that order through to a payment processor and delivery method? Script my meals for the week?
Everquest has you beat by a couple decades: https://www.nbcnews.com/id/wbna7020132
In that game you can type /pizza and it'll get ordered and delivered
Pizza Party beat this by a few years, I believe.
https://entertainment.slashdot.org/story/04/05/07/138238/piz...
That makes me miss the days when "but in 3D!" was a novel business model...
https://duckduckgo.com/?q=everquest+gameplay&t=fpas&iar=imag...
Hard to be formulaic when there's not a formula.
"Why not real pizza ingame?"
The Everquests certainly seem dated today, but for their time, they were pretty neat! The gameplay was simple (especially by today's standards), but it was a pretty unforgiving game that required a lot of teamwork. It was the social aspect that kept most people playing, I think, especially in guilds.
I remember a lot of the playerbase kept asking for significant changes to make the game less grindy and hardcore, but the main game designer would always push back and reiterate The Vision™ (in their words) and stick to their plans. Not only did they not ask for feedback, they would actively fight back against it and reinforce their stance. Well, they must've done something right... 25 years later, EQ is still alive, celebrating its anniversary, and making new expansions (after several sets of publisher/developer changes, though).
If not for EQ, we wouldn't have had World of Warcraft and all the other MMOs. But today's MMOs have all become basically "massively singleplayer" in that grouping is rare outside of guilds and limited end-game raids, with bots and boosters of various sorts taking the place of what used to require multiple real people (AI really IS ruining everything!)
The social aspect has been heavily deemphasized nowadays (Diablo and Destiny don't even have global chats anymore) and you mostly just see the ghosts of people doing their own things with no real need to interact with them anymore. Too bad =/
Showing off /pizza or other fun commands (emotes, music, crafting, etc.) was a big part of the old-school experience. These days there are still some semi-social MMOs (New World has an awesome group music jamming system, where multiple people can get together and jam like Rock Band/Guitar Hero: https://www.youtube.com/watch?v=ggWZJNnaLNU)... but sadly no more in-game pizza that I know of.
-----------
If anyone's looking for an old-school MMO in the style of EQ, Project Gorgon is an indie MMO made by (I believe) a mom-and-pop dev team: https://store.steampowered.com/app/342940/Project_Gorgon/
Or play old school eq: https://www.project1999.com/
Nice. I was wondering if this had been done somewhere before.
"Sony plans to integrate the pizza function more tightly into the game", which every game should do, of course :)
Game programmers: it’s a video game, we don’t need the same kind of application security that other programs do
Hacker: Hold my beer while I exploit this dude’s game client and makes it order 10,000 pizzas to his door
Why would you order 10,000 pizzas to someone else's door?
Unless you don't have 10,000 hungry friends.
To cost them a lot of money for all those pizzas. And to cost the pizza shop money if they can’t collect payment for the pizzas. And to cause general grief and misery, as trolls are wont to do :(
But, you could also not pay the money AND have the pizzas.
By killing the delivery worker?
AFAIK the ol’ unlimited free pizza by killing the thread trick no longer works. It sure was nice while it lasted, especially on platforms that easily let you kill a thread id, even kids could do it.
Remember how on BeOS there was a GUI for it? Great for unfreezing a crashed app that had state you wanted to try to recover or free leaked pizza.
Now worker threads spawned for delivery hold a lock preventing new pizza being placed in the oven for that address, which is not released until the add payment callback is successful. Destroy the only thread holding the lock, and pizza orders just queue up forever. :(
And you left a paper trail
That's why you order them to a neighbor's house who's out of town.
Eastern Europe's been having fun with variants of this since the 90s.
> Demonstrating a deep understanding of what its computer-gaming audience, Sony has built the ability to order pizza into its latest online multiplayer game.
NBC's command of language might not be good, but it turns out it is consistent.
>is ordering via ssh secure?# you bet it is. arguably more secure than your browser. ssh incorporates encryption and authentication via a process called public key cryptography. if that doesn’t sound secure we don’t know what does.
Strong disagree. The encryption is the easy part, the hard part is the symmetric key exchange. And PKI used by browsers is much more robust for this usecase then TOFU model of ssh. Of course the proper way to fix this is checking the ssh key fingerprint, but almost nobody does this.
Won't it warn you if you put the public key in your authorized_keys as shown here: https://www.terminal.shop/?
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.
Xterm is black on white by default.
Is there an environment variable defined for specifying if you want light or dark colours? If so, then it would help with local programs, and also with remote programs (such as this one) if you add a SendEnv command into the SSH configuration file to specify that SSH should use this environment variable.
A little non-portable but there is an xterm escape sequence[1] that gets the user's background color: \e]11;?\a
You might also be able to use the reverse-video[2] escape sequence to get something that works depending on the user's color scheme.
The whole system wide light/dark stuff came about too late to help our terminal sessions.
we meant to have this fixed before launch, but ran into some snags with charm's `wish` and adaptive colors.
shipped an improved light mode today!
"Shell company" takes on a new meaning!
Really cool interface. Is there any list of such servers publicly available through ssh?
Some of the older still-available services are listed below
SSH: ascii.theater was mentioned here, so was mapscii.me There's a bunch of games at https://overthewire.org/wargames/ (and there's likely still dozens of other small muds running over telnet as well) chat.shazow.net is a chat server
Non-ssh (the games mostly require registration): `curl wttr.in` for weather `finger help@graph.no` for weather `cat | nc termbin.com 9999` for a pastebin `telnet telehack.com` `telnet freechess.org` `telnet gt.gamingmuseum.com` `telnet fibs.com 4321` to pay backgammon
There's used to be Nyan cat through telnet, which I'd hacked into running on ssh but AFAICT there's no longer any servers around (my own server is no longer around either) https://nyancat.dakko.us
Unknown how many of these are running still: https://info.cern.ch/hypertext/DataSources/Yanoff.html There's a much more recent list that includes ssh and telnet services here: https://github.com/chubin/awesome-console-services
---
On a related note, http://shells.red-pill.eu/ lists a bunch of free shell services.
I remember some blog post that took comments via ssh, that was cool as well.
create the next ssh crawler
Love the idea! Congratulations (?) on being sold out!
My constructive feedback is that the text contrast is so low (in iTerm2 anyway) I can barely read anything. I thought only web pages had that problem, but I guess sufficiently sophisticated TUI apps have designer color problems too! What's next, incredibly tiny terminal fonts? (jk, designers...sort of)
I wasn’t the one who made this, fwiw.
I really like Fellow Drops: https://fellowproducts.com/pages/fellow-drops
It is SMS based. Each week they offer a different bean from a different roaster, and you reply with the number of bags you want. I've discovered a number of great roasters this way.
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.
You are not wrong.
But beware the predatory lawyers who will come after you for ostensible violations of California’s Invasion of Privacy Act, California Penal Code section 630, et seq. (“CIPA”).
One company I work with received multiple arbitration demands (claimed "privacy" damages in excess of $25000 each, helpfully offered to settle for $5000 each!). And this company didn't even set any cookies or run any 3P tracking on their site!
Their (famous-you-know-them, expensive, California-based) lawyers said "yes, we are seeing this more and more. We can fight and win for $200K, or you can pay the $50K of claims outstanding and add a banner to your site".
Their CEO chose the less-expensive option. :-/
Does the law even matter in this case? If the idea was to make you convinced you'd spend $200k to win a bogus case, you can be sued for literally anything...
This is true, but CIPA is the law that is being exploited for its ambiguous applicability. There are lawyers out there actively targeting companies who legitimately believe they do not need a cookie banner.
They seek out customers of the company ("Are you now, or have you been, a customer of X? You may be the victim of Y/eligible for legal settlement Z/etc.") They may even identify the corporate targets, and recruit new customers for their purpose.
And the way to avoid the issue completely is to add a stupid, superfluous, cookie banner. (Which, in the height of absurdity, requires adding a cookie).
It was a painful and semi-expensive lesson for this small company. And their expensive/prominent lawyers say they are seeing the problem increasing. (I asked why they didn't take the time to warn their clients, but did not get a satisfactory answer).
So it's worth a thought and a note when the idea of not needing a cookie banner comes up.
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.
> It's only when you engage in user-hostile practices, such as tracking, that you need to ask for consent.
Which is what the majority of sites want to do which is why there is a good reason for a cookie banner, by definition.
I believe that you need to inform users about the use of strictly necessary cookies as well. You just don't have to ask for consent before adding them.
> While it is not required to obtain consent for these cookies, what they do and why they are necessary should be explained to the user.
There's nothing about a cookie banner in GDPR, it's just the most convenient (and, often, laziest) solution to the question of how to confidently say you've told users something.
But what if I want coffee and a cookie?
Can I interest you in this delicious cup of Java?
there was never a need>No need for a cookie banner.they get your ssh public key which is a unique identifier so that should be disclosed.
It's a public key. You should operate under the assumption that anyone could have it at any time.
Still, it identifies you so it can be used to track you over visits to many different stores-over-ssh, just like third party cookies.
Lol, the subset of people buying coffee via ssh and shopping elsewhere via ssh is going to be insanely small, they can probably already more or less track you.
Additionally, you're probably giving a shipping address and using a card number of some sort.
Its extremely difficult to shop anonymously online for physical goods.
> Lol, the subset of people buying coffee via ssh and shopping elsewhere via ssh is going to be insanely small
Yeah, nerds. In the FAQ there is the question "What is SSH", and the answer is - "If you have to ask then it's not for you".
Edit: Seems the FAQ may have been updated or this simply wasn't part of the online version, https://imgur.com/a/igjGCFM here is a section of the FAQ sent to my email.
You could use one key per service. Almost like a passkey.
You could work around this with different private/public key pairs?
if you are aware of other stores-over-ssh, I’d genuinely love to hear about them because this one is so fun. Or even not-stores that are reachable via ssh. Any MUDs still going?
You might like https://tildeverse.org/!
Doesn't seem to work:
fragmede@samairmac:~$ ssh tildeverse.org fragmede@tildeverse.org: Permission denied (publickey).That's because you're using the wrong protocol. Try https in the browser to see their website.
Oh, it seems to rickroll people with a referrer from this site :)
Copy-paste or manually type the URL to get around that!
Edit: They seem to be redirecting with a 301 permanent HTTP response, which seems slightly obnoxious since your browser might cache it. I can't visit the site anymore from the browser I'm using here, so maybe try a different one or incognito mode.
Why would I do that? I'm looking for ssh toys, like ssh starwarstel.net or ssh funky.nondeterministic.computer.
That's kinda what I thought about emails too but ... somehow that has changed.
what does that have to do with disclosing the potential for tracking?
it's a dessert topping and a floor wax
If they aren't logging it then there's nothing to disclose.
If IIS had won the server wars, your MOTD could give you targeted ads based on exactly this. Oh, the innovation!
it's a us company they don't need a cookie banner anyways
Be careful. If you have California customers you need to worry about California’s Invasion of Privacy Act, California Penal Code section 630, et seq. (“CIPA”).
It's not clear that it applies to the web! But predatory lawyers will come after you for it, if you are big enough and don't have a cookie banner.
I mean, if they somehow ported google analytics (or some other brokered PII network) I think they technically would need consent and disclosure.
They'd only need a cookie banner if they somehow could put a cookie on your machine using SSH.
Depending on how they're using any personal data you provide, they likely wouldn't need consent: for instance, if they use the personal data you provide to ship you your order, they don't need to ask (you supplied your information for the express purpose of placing an order, after all). However, if they want to do more with that data, they'd need consent.
The authenticity of host 'terminal.shop (172.65.113.113)' can't be established. ED25519 key fingerprint is SHA256:TMZnO7N8mmR/Pap3urU2P4uBNuhxuWtDUak0g9gyZ8s
That's a bit different than the key listed
No. The key listed is the whole plain ed25519 pubkey (those are relatively short). The message displays the SHA256 digest.
You can check that in your local known_hosts file (after having connected at least once) with "ssh-keygen -F terminal.shop -l" and "ssh-keygen -F terminal.shop -lv". (Yes, it is confusing that the command is named "ssh-keygen" but does lots of things that are not about generating any keys)
If you want to do it without connecting, try "ssh-keyscan terminal.shop".
Have you added the required line to ~/.ssh/known_hosts as described on their website?
That's not actually what they describe. They describe catting known_hosts and seeing terminal.shop with the given key in the output. That won't work if you don't continue to connect because known_hosts won't be updated with their key. Additionally, if hosts are hashed, you won't see terminal.shop anyway.
I think what "cat" here means is that you are supposed to add their key to the known hosts file manually before you connect. Showing the output of "cat file" is a way of saying "this should be in the file".
I think it’s fair if they want to assume a certain competence from their audience, and they’re being cute. But these aren’t instructions and if they are, well, the ssh command happens first.
Reminds me of
"Before Google, Sergey Brin tried (and failed) to let us order pizza by fax"
solaris used to have a pizzatool
EDIT: image here: https://blog.adafruit.com/2022/01/31/the-story-of-sun-micros...
I might be horribly out of touch, but... is $25 for a 12oz bag of not-totally-horrible coffee beans really a normal price?
No. 12oz Dunkin is like $9 at Target, same with Starbucks medium roast; Pete's is $12. The most expensive stuff is this mushroom chuga coffee (I have no clue what this is) for $16/12oz. And Target is generally more expensive than most chain supermarkets.
So no, not a normal price.
not normal price for anything you'd find in most grocery stores.
but as an anecdote, I get a lot of coffee from the Fellow Drops subscription service, and those bags average around $25 - often for less than 12oz.
The best local roaster in my town charges about $20 for a 12oz bag of specialty single origin coffee. Their blends are a little cheaper even.
The lowest price specialty coffee I could find online is about $12 for a little over 10oz from a place called S&W.
So $25 is a very bad value in my opinion.
~$15-$20 for a 12oz to get it fresh from a local roaster in the SFBA.
You're paying for the convenience.
Reminds me of my friend’s zine-via-telnet: https://anewsession.com/
Now /that's/ interesting! Thanks for the link - I must try this myself...
If you're looking for a movie to enjoy with your coffee, https://ascii.theater/
ssh -a -i /dev/null -o StrictHostKeyChecking=no watch.ascii.theaterI raise you:
telnet mapscii.me
It's sold out and the only option if you actually connect via ssh is to give them your email address so they can send you updates.
Hah, they went awesome and implemented an SSH interface, and they ended up with an unescapable "subscribe to our fucking newsletter" prompt anyway...
Makes me wonder if this is just a ploy to email harvest and there never was any coffee being sold.
They were mentioned 2 and 1 days ago, and weren't sold out then.
There’s always risk exchanging money and information with a merchant regardless of where and how the transaction takes place. And SSH is a fairly unconventional way to run a business so that’s a point in favor of extra caution. That said, tit is pretty unlikely to be a scam. Two of the team members are theprimeagen and teej_dv; both longtime twitch/youtube streamers: with a reasonable following: one of whom is a core neovim maintainer. They streamed the development of most of this live on twitch. They have a reputation to uphold and a track record of other publicly facing work to help support the legitimacy of this venture. Sadly, the VOD requires a subscription and the source isn’t available (though they said they plan to open source it) so there’s not much to fall back on other than hearsay until the orders start arriving or the code gets posted.
The Primeagen is behind this, and they had physical samples at react whatever in miami recently for whatever that's worth
all the guys involved with this are public and legit. you just happened to look after they were sold out. I ordered some just fine.
for backend dev recruiterspam
Ah lame, they won't even let you browse since they're sold out.
I believe it's just a stub for collecting emails. Nothing more.
Edit: somebody was able to order coffee through them (see below).
Nope! It is real, I was able to order some coffee a few days ago. Will report back on if it shows up or if it is any good :)
Oh, cool! That gives me hope.
Well I hope they enjoy getting a lot of fake emails, because that's what's gonna happen.
Many people forget that their email is included in the public key that is presented to the ssh server by default. So, the email collection form is actually somewhat redundant.
But yes, I added my share of funny email addresses to their list. Tradition is a tradition.
What do you mean? Public keys don't usually include an email address. They have an id that's usually in the form "user@host" but that's unlikely to be a valid email address. Maybe some systems use an email address there, but none of those I know.
> They have an id that's usually in the form "user@host" but that's unlikely to be a valid email address.
They are valid email addresses most of the time, in my experience. :)
A valid email address isn't the same as an email address that actually has an inbox behind it. Some of my ssh keys have an fqdn but there's no mx record configured for it. I used to use my bare domain, which does have an mx record, but I've never used real mailbox names for the ssh keys.
All of my ssh keys are chuck@hostname, which is the default output of ssh-keygen. I’ve never had a valid email in any of my ssh keys.
Oh mine sure isn't. Mine is username@hostname, which doesn't even get you close to my email.
Regardless, I connected with:
Really tempted to write a bot to spam that form... but I'll give them the benefit of the doubt and wait to see if they come back in a week or so.ssh -o IdentityAgent=/dev/null -i /dev/null terminal.shopI just don't get why I can't read the FAQ even though they're sold out. Kinda missing their moment here by having nothing to do other than give an email and quit.
Was kinda hoping this was some place selling made coffee, but I do realize the reach of that would be small.
But I do kinda like the idea of something as... niche as this popping up in a highly tech area and then offering the ability to buy and get your coffee without ever seeing someone.
Like you just walk into a room with a rotating door (like one you might see at a doctors office for samples) or something like that.
Feels very... introvert and would be kinda fun.
The founders have a great (if conversational and sometimes off topic) podcast about development topics:
https://podcasts.apple.com/us/podcast/how-about-tomorrow/id1...
"Universal" podcast link: https://pods.link/i/1651741524
From the FAQ:
will Nil make me a better developer?
legally we cannot guarantee that it will, but...
is it true your coffee contains the sweat of @theprimeagen?
we can neither confirm nor deny these rumors.
is it true your coffee contains the tears of @thdxr?
yes, this is true.Reminds me of prose.sh. Turns out, there’s a lot you can do if you SSH keys as an authentication mechanism!
FAQ:
> is ordering via ssh secure? you bet it is. arguably more secure than your browser. ssh incorporates encryption and authentication via a process called public key cryptography. if that doesn’t sound secure we don’t know what does.
Doesn’t TLS use public key cryptography too?
"More secure than your browser," while serving the hostkey over HTTPS.
It would be awesome if I can do something like this:
> ssh terminal.shop "register foo $pubkey"
> ssh foo@terminal.shop "set shipping address to $addr, credit card info $info, email address $email"
> ssh foo@terminal.shop "order one 12oz light roast"
hope you clear your bash history after a purchase :)
That would be really cool and quite simple to implement because ssh supports command execution
Claim to be ethical, yet don't deliver in the country the coffee is actually made.
Reminds me of the pizza cli app that would order Domino's Pizza.
EDIT Pizza Party is what I am thinking about.
Prime and Teej streamed the development
Another service that is completely controlled through a ssh tui : https://nixbuild.net
This is really cool. I wonder how they pipe the data to stripe?
As an aside kind of funny to see this pop up. I was just talking about if anyone was doing ordering through a cli a while ago: https://news.ycombinator.com/context?id=39817617
With the stripe api Why would their backend be different then any other website using stripe
I love this. If you love this, you might also like a game I built a while ago:
$ ssh sshtron.zachlatta.comI 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
While it's cute, it's a small business not a startup and still a gimmick that doesn't solve the problem that coffee is a commodity and so the business is fundamentally not defensible. It's equivalent to being a meal kit business, which is one notch away from being a restaurant.
Since I can't currently order, can someone say how the ordering process works? Do they send back a link to be used with stripe? Or do they try to handle everything within the terminal? The latter seems to invalidate their claim that this is just as secure as using a web browser.
Is this a reverse-Dropbox play? Make something need ssh, rsync, etc. that didn't need it before.
$25 for 12 oz? Yikes!
With 70$/kg that's at the upper end of typical prices for specialty coffee (though I'm not familiar with US prices specifically). No idea if they are at a level where they can compete at that price point, a single blend as main product is rather odd for a coffee roaster. At this price point you'd usually get various single origin coffees.
what did you expect when they said "startup" and not "shop"
Free coffee in exchange for all future rights to my productivity metrics.
knowing "startups" i'm sure their vision is streaming SSH subscription as a service . They track your keystroke rate and automatically ship new batches of $2/oz coffee when you get below 90 keystrokes/min
No joke, but "startup" can often be code for, "extremely high-quality items that are subsidized by VC money". The quality doesn't last, but if you get in early, you can often buy stuff that's way nicer than it should be for the price.
i would frame this comment if I could.
Early AirBnB, Lyft, Uber, Lime, Bird, Netflix, online-retail were very high quality for low cost and then inverted.
Guessing you’re not an Onyx Coffee fan then? =)
I'm sticking to costco.
$2 / oz via ssh or 50₵ / oz via Costco
More like 30₵/oz.
Looks like they're sold out now.
The "enter your email for restock updates" part of the screen showed up as white-on-white on my light-mode-by-default Gnome Terminal on my first try and so I was slightly confused; sshing from `uxterm` worked fine though.
How does scaling work for SSH? e.g. How many concurrent connections can the server handle?
Neat — big fan of TUIs! But I’m an even bigger fan of coffee… so show me where that coffee actually is sourced from…
Did you go and source it from farms? Is this sourced from another company? Whose blend? Do you provide the roast date on the bag?
I love TUI's. And now that Sixel exists, we can even have images in the Terminal.
The massive simplification this provides over rendering HTML/CSS should be attractive to startups.
Now I wish we had a CLI/TUI for things like Amazon...
So cool! Congrats on selling out!
I was curious to see if I could connect using mosh. I could, but I wasn't able to use the hotkeys to browse the different screens like I was when I connected via ssh.
I would not be upset if the entire internet went back to this.
Happy to see this didn't work
scp foo.txt terminal.shop:.
Though obviously, something like
orscp evil_passwd_file terminal.shop:/etc/passwd
is really the kind of thing you don't want. But if you can't copy foo.txt into your home directory, you probably can't copy attacker versions of more sensitive files into sensitive locations.scp evil_authorized_keys terminal.shop:.ssh/authorized_keys
This is so cool! Just imagine a world where you can run `getcoffee latte` and have a latte show up at your door 20 minutes later.
Most of these APIs already exist, just that they are hidden behind custom apps and auth walls. For example you can order coffee on starbucks.com or doordash.com right now and see all the network requests which facilitate the delivery.
Your receipt: - latte 5.99 - delivery fees 5.99 - ssh fees 0.99 - internet fees 0.59 - water 0.19 - sewage 0.09 …..
Wait, what?Sub total 5.99 Total. 10.80someone call the ftc lol
I wanted to ask if they do telnet/finger also, but there is no email listed.
Cool concept, but quite limiting if you are selling a mass-market product.
Slack preview link shows up weird. It shows as follows
> wip: terminal (initial commit)
They sold out in 15 minutes? Or this is email/ip addy harvesting?
From their Twitter, they sold out yesterday. OP must have just thought it was interesting regardless, even if it's a suboptimal time for them.
This is really cool. Which tech does it use for ecommerce functions?
I've been toying around with an ssh based casino recently.
Man, consumerism is a powerful drug. Just one gimmick needed.
In this case, caffeine would be the literal drug.
I mean, some of us are going to buy and drink coffee anyways.
This is genius!
Not sure how the stripe payments intake work but very cool!
Looking forward to reading about this incredible journey
This is cool; I wish they had decaf single origin!
I would really like to see a decaf option there.
Does ssh have a good payment system built in?
Are the beans any good, what kind of roast?
"Dive into the rich taste of Nil, our delicious semi-sweet coffee with notes of chocolate, peanut butter, and a hint of fig" and "medium roast"
Oh, is that in the email or something?
I searched Nil blend coffee but only got results about sports teams.
I wonder if it is white-label or something.
Kind of disappointed that there is no option for commands like “ls” or “whoami”. I think it would be a nice addition, especially if this inspires other people to launch similar pages for other types of products.
Scared to order after xz exploit...
Same here, I know Prime tho. I really looks fun, but sound scary
Hey terminal.shop, Y U No T? :-(
Page title: wip: terminal
That is objectively a worse title than what is submitted - which explains what the page/product does.
Who has this problem?
zero interest rate startups are still in fashion I see.
What makes you think any small business like this would need to get VC funding for a website and a simple tui program with a couple features?
People make cafes and coffee shops all the time without taking money or at least VC money.
they're self-funded, there's no interest rates present.
only if they spunoff their ssh based shopping cart with stripe integration to a vc funded startup.
hopefully using a java implementation of an ssh server
I'd bet it is probably Golang and using this: https://github.com/charmbracelet/wish
ssh -v reports remote software version Go, immediately looked like the charm stack to me as well
ok cool gimmick but why? is it special coder coffee?
sure, but can I sudo a sandwich ?
Sold out :(
CHROOT
suuuuper gay
now, I want to sell ketchup over SSH.
Not to dunk on the coffee which I haven't tried but this seems like a viral ad? I get it's cool that this actually works, but in practice how is it different to selling coffee through an API through a generic web interface served by shopify? In the end in both ways they are selling you coffe beans for money. It's still cool to see it in your terminal though.
> It's still cool to see it in your terminal though
This is the whole point, I think. Things can exist just because they're fun :)
They are missing out.. There are some Tor customers out there...
"STRONG KEYS, STRONG COFFEE"