ssh -a -i /dev/null terminal.shop

    ssh terminal.shop

If you want to make sure no keys are offered, you'd want:

  ssh -a -o IdentitiesOnly=yes terminal. Shop

    ssh -v -i /dev/null terminal.shop

    ssh -v terminal.shop

    debug1: Offering public key: /Users/fragmede/.ssh/id_rsa RSA SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

    ssh -a -i /dev/null -o IdentityAgent=/dev/null terminal.shop

Upon further testing,

    ssh -o IdentitiesOnly=yes terminal.shop

  ssh -a -i /dev/null -o IdentityAgent=/dev/null terminal.shop

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.

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

  /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

Agent forwarding is a whole other beast.

    ssh -o IdentitiesOnly=yes terminal.shop

    ssh -o IdentitiesOnly=yes -o IdentityAgent=/dev/null terminal.shop

    ssh -a -i /dev/null -o IdentityAgent=/dev/null terminal.shop

(It’ll still offer public keys by default in the exchange, but that’s “just” a privacy issue, not a privilege escalation problem.)

    bwrap --dev-bind / / --clearenv --tmpfs ~ --unshare-pid --as-pid-1 --die-with-parent ssh terminal.shop

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

Not at all specific to this.

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.

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

My assessment still stands. Use proxyjump (-J) instead of proxy command whenever possible.

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.

As far as I’m concerned the baby and the bath water is just a normal expression.

I thought it was something about the use of “confirm,” haha.

So I can see where someone might count it toward buzzword bingo. But this post also offered an alternate solution when saying "baby+bathwater", so the bingo caller should refuse to score this one.

Learned that rule the hard way. It’s crucial to the success of HN and I am grateful dang corrected me.

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.

You're allowed to draw sensible boundaries.

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?

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.

Still I'll be sure to break up my keys more going forward and disable SSH forwarding.

  ssh -o PubkeyAuthentication=no -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -a [email protected]

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.

It's also good to see if any malicious process tries to make use of the agent locally!

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.

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.

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 :/

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.

[1] https://www.brow.sh/

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.

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.

---

[1] https://docs.stripe.com/security/guide

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.

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

https://github.com/NARKOZ/hacker-scripts

[ 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 ]

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

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

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

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

  ┌──────────┬────────┬─────────┬───────┬────────────────────┐
  │ 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 exit

Something like hypercard implemented with 80x24 ncurses UI

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.

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.

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.

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

I wrote up a little demo and explainer at

   https://mitm.terminal.shop.rag.pub
  
   ssh mitm.terminal.shop.rag.pub

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:

    $ ssh [email protected]
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    @    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.

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.

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.

letsencrypt is free, you might hate the browser for many fair reasons, but PKI and the CA/B forum are actually effective.

Can I pipe that order through to a payment processor and delivery method? Script my meals for the week?

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/

"Sony plans to integrate the pizza function more tightly into the game", which every game should do, of course :)

Hacker: Hold my beer while I exploit this dude’s game client and makes it order 10,000 pizzas to his door

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

NBC's command of language might not be good, but it turns out it is consistent.

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

This is the whole point, I think. Things can exist just because they're fun :)

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)

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.

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

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.

Which is what the majority of sites want to do which is why there is a good reason for a cookie banner, by definition.

https://gdpr.eu/cookies/:

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

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.

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.

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.

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.

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.

That's a bit different than the key listed

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