429 comments

[ 3.5 ms ] story [ 317 ms ] thread
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

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

(comment deleted)
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. :(

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/

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

Page title: wip: terminal
That is objectively a worse title than what is submitted - which explains what the page/product does.
Interesting. I like this. No need for 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.

But what if I want coffee and a cookie?
Can I interest you in this delicious cup of Java?
they get your ssh public key which is a unique identifier so that should be disclosed.
If they aren't logging it then there's nothing to disclose.
It's a public key. You should operate under the assumption that anyone could have it at any time.
it's a dessert topping and a floor wax
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.
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.
You could work around this with different private/public key pairs?
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.
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?
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.

  >No need for a cookie banner.
there was never a need
There is never a good reason for cookie banners, by definition.

The rule is that if you have a good reason for your cookies (i.e., basically one that isn't user-hostile), you have nothing to worry about and don't need a cookie banner.

It's only when you engage in user-hostile practices, such as tracking, that you need to ask for consent.

I'm being sightly snarky, but that's really the essence of it.

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

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

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.

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.

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.

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

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.
Makes me wonder if this is just a ploy to email harvest and there never was any coffee being sold.
The Primeagen is behind this, and they had physical samples at react whatever in miami recently for whatever that's worth
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.
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.
Hah, they went awesome and implemented an SSH interface, and they ended up with an unescapable "subscribe to our fucking newsletter" prompt anyway...
Reminds me of prose.sh. Turns out, there’s a lot you can do if you SSH keys as an authentication mechanism!
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.

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.
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.
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 wanted to ask if they do telnet/finger also, but there is no email listed.
Really cool interface. Is there any list of such servers publicly available through ssh?
create the next ssh crawler
(comment deleted)
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.

See also: https://github.com/Swordfish90/cool-retro-term

I remember some blog post that took comments via ssh, that was cool as well.
I long for an alternate dimension where terminal-based internet like Minitel dominated .

Something like hypercard implemented with 80x24 ncurses UI

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

Responsive, high-contrast, low bitrate, low complexity
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
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.

"Most people can't even find the turn off ads button in windows 11"

Perhaps the problem there is incentives.

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.

$25 for 12 oz? Yikes!
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.

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.
Guessing you’re not an Onyx Coffee fan then? =)
I'm sticking to costco.
$2 / oz via ssh or 50₵ / oz via Costco
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.
Scared to order after xz exploit...
Same here, I know Prime tho. I really looks fun, but sound scary
One safety tip: disable SSH Agent Forwarding before you connect, otherwise the remote server can theoretically reuse your private key to establish new connections to GitHub.com or prod servers (though this host is unlikely malicious).

https://www.clockwork.com/insights/ssh-agent-hijacking/ (SSH Agent Hijacking)

The full command you want is:

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

    ssh terminal.shop
to connect.
I'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:

  ssh -a -o IdentitiesOnly=yes terminal. Shop
I'm not sure if the `-i` actually prevents anything, I believe things other than /dev/null will still be tried in sequence.
instructions not clear, my entire drive is empty now
Check for yourself with

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

    ssh -v terminal.shop
What you're looking for is that there is no line that says something like

    debug1: Offering public key: /Users/fragmede/.ssh/id_rsa RSA SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Upon further testing, the full command you want is:

    ssh -a -i /dev/null -o IdentityAgent=/dev/null terminal.shop
to forcibly disable a local identity agent from offering up its identities as well, and not just agent forwarding.

Upon further testing,

    ssh -o IdentitiesOnly=yes terminal.shop
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.
For 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.
(comment deleted)
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.

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

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

  ssh -a -i /dev/null -o IdentityAgent=/dev/null terminal.shop
That looks pretty solid. Thanks!
Hm I thought I'd edited this. I was mistaken,

    ssh -o IdentitiesOnly=yes terminal.shop
works as expected, however I had an IdentityAgent set, and my key was being submitted via that route.

    ssh -o IdentitiesOnly=yes -o IdentityAgent=/dev/null terminal.shop
behaves as expected; same as

    ssh -a -i /dev/null -o IdentityAgent=/dev/null terminal.shop
Verified via whoami.filippo.io.
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.

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.
I just ran it in a `tmpfs` without any credentials:

    $ bwrap --dev-bind / / --tmpfs ~ ssh terminal.shop
I 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`.

    bwrap --dev-bind / / --clearenv --tmpfs ~ --unshare-pid --as-pid-1 --die-with-parent ssh terminal.shop
(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!)
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.)

(comment deleted)
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.
*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.
[flagged]
Sorry, English is not my native language. I know I sometimes sound strange because most of my use of the language is around the internet and at work, not that much casual "normal" conversation.
English is my native language and I have no idea what that person was talking about. Your post is fine.
I think that person was talking about having had 4 out of 5 squares in a line on their bingo card already, and stumbling across "baby+bathwater" earned them bingo. The card is metaphorical though... more of a mental buffer that just overflowed.
That makes more sense than my solution.

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.

Mine too, and I think the post is fine also, but I have some idea of what that person was talking about. For a while, in some corporate environments, it was a recurring phenomenon to hear someone dismiss an urge to be cautious by saying "You're throwing out the baby with the bathwater."

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.

Your English is fine. That person was violating HN rules about snark (“Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.”)

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

I don't see a rule where joking is prohibited. People sure love their buzzwords though. Must bring them a feeling of synergy in these unprecedented times :)

Glad that at least a few people above got the joke

Did I mention joking?
In your list of prohibited items? No. That's my point.
Or use a hardware backed ssh key you have to tap once for every use, like a Yubikey or Nitrokey.
> 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?

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

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.

(comment deleted)
"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 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?
Maybe there was some blanket advice in the past to enable it? Idk, this got me alarmed for nothing.
The man page for ssh_config(5) says that it is set to "no" by default, at least on my computer.
It's off by default. No idea what this fuzz is about. Gathering internet attention points maybe?
Is "Host * \n AddKeysToAgent yes" acceptable from a security POV or should that also be per host?
Default is disabled.
Exactly, this tip only applies if you reconfigured ssh to automatically forward agent to all hosts, which is absolutely insane.
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?

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.

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.
If anything it's more standard practice to have agent forwarding disabled, since that's the default.
> 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.

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
(comment deleted)
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.
And for privacy, don’t let it know your identity or username:

  ssh -o PubkeyAuthentication=no -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -a nobody@terminal.shop
Otherwise, the remote server can probably identify who you are on platforms like GitHub.
What I am reading from this there be dragons so don't use SSH to buy coffee!
Dang. Didn't know this was a thing. Thank you!
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.
It is not the default, you would have to have a silly config for this to matter.
AFAIK, that’s exactly how agent forwarding works. The explicit part is that you need to explicitly turn it on
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.
You actually want to verify first or someone will mitm you, e.g. mitm.terminal.shop.rag.pub
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.

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.

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

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!

here we go again. domain and path restricted cookies anyone?
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.
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
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.
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.
(comment deleted)
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...

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.

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