jamiesonbecker

> nor operating a McDonalds

That was a quote of the parent.

Until last year (when he was 95), he was operating the world's largest holding company by assets and revenue.

It was also the first non-tech company to reach $1T market cap.

And, its class A stock was by far the most expensive stock in the world at $740,000 per share, more than 100x more expensive than any other US stock.

So, yeah, I think he'd be qualified to operate maybe even two McDonalds. Maybe he could even be driven to them.(Coincidentally, he is a HUGE McDonalds and Coke fan and has eaten there almost every morning for over 50 years.)

Disrespecting older people seems to be a hobby as old as Father Time.

True, but that prevalence is not a constant. In fact, across the broader landscape of human history, that appears to be a relatively recent development, and almost certainly environmental/toxins related. For example: https://www.newscientist.com/article/2479344-dementia-cases-...

> don't think 80+ year olds should be driving a car or even operating a McDonalds

Warren Buffett is 96 years old. Knowledge and wisdom tend to increase with age.

> Starting Oct. 16, exporters must register with the authorities if they plan to transfer intellectual property to overseas entities, grant licenses to foreign companies to use Chinese technology, or transfer ownership of Chinese technology to any foreign party, according to the ministry.

@dang for some reason, the original link was instantly [dead]. Is epochtimes a banned site?

EasyDNS

Very unexpected behavior, esp for those with several accounts and phone numbers, intending to keep them separate for security or other reasons.

I did notice that you tried to mitigate the risk, but why not just pick a high port rather than this complex redirection?

Your scheme is smart and creative but unnecessarily risky.

SSH can do remote listens to the world by itself, no second nginx needed, but sish or ngrok might be a better solution for the general case.

Anytime you punch holes, you're taking a risk, so make it as narrow as you can.

This is wildly over-complicated and also has a bunch of footguns and security risks.

For example, that very first NGINX section allows an attacker to direct their incoming traffic to any arbitrary listening port on localhost. They can even write a simple for loop in bash that would use curl to test all of the different ports. This also bypasses any firewall rules that you might have blocking traffic from the outside world.

be very careful following the instructions in this article.

Read the man page for SSH, and especially the remote forward section. https://man7.org/linux/man-pages/man1/ssh.1.html

See also Brave Origin: https://brave.com/origin/

It's Russia 1917 or Cuba 1959 all over again.

But it'll be different this time! Right?!

I ran back to grab my towel, but my house was getting bulldozed.

This is incredibly cool. I tried telling it to both turn up the temperature in the home and turn down the lights in the LR and got a beautiful JSON doc.

Esp paired with a small Whisper or Parakeet voice model, this enables some amazing real-world use cases in lower-power situations (car, marine, home, PLC, industrial automation). Combining with a solar/wind combo for your home could be incredibly interesting.

That's incorrect. It's not only perfectly acceptable, but absolutely vital, to pay someone for their services (incl a customer) for assisting with an existential threat against the corporation.

Any counsel or HR who would draft a corporate ethics rule that wouldn't allow for a bug bounty to be paid out on a massive vulnerability, merely because the person was "a potential customer", should be immediately replaced.

`crontab -e` and add:

  # at 3am every day.. 
  * * * 3 0   cd ~/src; claude -p "find and fix bugs and commit"

Rotating keys is easy with the right software. (I work @ Userify) Agree with the auditing point

Token-based keys, to tptacek's point, is that they can be a giant pain once you start scripting across fleets.

One key per device is exactly what we recommend too. Private keys should always be protected as much as possible within that device and should never leave that device.

Just paste all of your devices' public keys into your authorized_keys file and leave a comment at the end for what device it's for. in Userify, it literally goes right into your nodes' authorized_keys file almost verbatim. (disclaimer: I work at https://Userify.com)

And then, if you leave your token or laptop at the airport or whatever, just remove that key right from your phone and it'll take effect in seconds across all the nodes/instances (if you're using Userify) or you can just write a quick for-inline-sed loop to remove it from your authorized keys everywhere.

The next one linked at the bottom, https://jonno.nz/posts/stealing-nanoclaw-patterns-for-webapp... has this bold and frankly unbelievable claim:

"70% of startups fail due to premature scaling"

.. which is a link to another blog post somewhere else that says nothing even slightly related.

Then install your own:

    curl i.userify.com | sudo - sE

The experience might be better right up until you're running it in prod and someone happens to ask about:

   Cert revocation (or even expiration)

   Sudo roles

   User removal and process termination

   Is the cert server HA and locked down

   How you log in when the cert server is down or under attack (rich target!)

   How to easily add Alice to server group A, Bob to B, and Carlos to both A and B, and then to remove them..

(disclaimer we're celebrating our 15th anniversary at https://Userify.com, but those are actually legit concerns and not only a sales pitch. You certainly can build a solid and secure ssh cert infra, but doing it in production is just not an easy set-it-and-forget-it sort of thing.)

Honestly, we used to replace a lot of pam_ldap and similar sorts of awful solutions. With those, if your LDAP went down even for a heartbeat, you couldn't log in at all.

So I totally agree: if I had to do certificates and didn't have something like Userify, a 1 hour (or even shorter if possible) expiration seems quite worth chasing, especially with suitable highly available configuration. (Of course, TFA doesn't even bother mentioning revocation and expiration, which should give you a clue as to how much fun those are lol)

And for more normal, lower-security requirements or non-HA, 6 or 8 hours or so would probably work and give you plenty of time for even serious system outages before the certs expired.

Not to hard shill or anything (apologies in advance, just skip if you're not interested), but there are two significant security and reliability differences between standard SSH (with or without certificates) and Userify:

1. Userify Cloud updates by default every three minutes, and on-premise Userify Express/Enterprise updates every ten seconds, but it doesn't have to update at all; even if your Userify server goes offline forever, you can still log in because the accounts are standard UNIX accounts (literally created with `useradd`)

2. When accounts are removed, Userify also completely nukes the user account, removes its sudo perms, and totally kill -9 's any tmux/screen/etc sessions (all processes owned by the user are terminated across the entire enterprise within seconds), which is also not something that a certificate expiration would ever do.

Great question. Not yet ;)

Well, TOFU is really just the model for how the chain of trust is established.

In practice there isn’t really trust on first use: there’s verify the key matches what’s expected, or distribute keys out-of-band (including certs).

If that verification step isn’t happening, then it’s not TOFU, it’s just blind trust.

From an automation/autoscaling angle, the same thing shows up again:

1. either keys are pre-baked / distributed

2. or, something signs them at boot

Signing an instance key is just another way of distributing trust. It doesn’t remove the need for a root of trust, it moves it.

Certificates just add extra steps around the same underlying task.

That works for authn in the happy path: short-lived cert, grab it, connect, done.

Except for everything around that:

* user lifecycle (create/remove/rename accounts)

* authz (who gets sudo, what groups, per-host differences)

* cleanup (what happens when someone leaves)

* visibility (what state is this box actually in right now?)

SSH certs don’t really touch any of that. They answer can this key log in right now, not what should exist on this machine.

So in practice, something else ends up managing users, groups, sudoers, home dirs, etc. Now there are two systems that both have to be correct.

On the availability point: "reasonably available" is doing a lot of work ;)

Even with 1-hour certs:

* new sessions depend on the signer

* fleet-wide issues hit everything at once

* incident response gets awkward if the signer is part of the blast radius

The failure mode shifts from a few boxes don't work to nobody can get in anywhere

The pull model just leans the other way:

* nodes converge to desired state

* access continues even if control plane hiccups

* authn and authz live together on the box

Both models can work - it’s more about which failure mode is tolerable to you.

SSH certs quietly hurt in prod. Short-lived creds + centralized CA just moves complexity upward without solving the core problem: user management.

The system shifts from many small local states to one highly coupled control point. That control point has to be correct and reachable all the time. When it isn’t, failures go wide instead of narrow.

Example: a few boxes get popped and start hammering the CA. Now what? Access is broken everywhere at once.

Common friction points:

     1. your signer that has to be up and correct all the time
     2. trust roots everywhere (and drifting)
     3. TTL tuning nonsense (too short = random lockouts, too long = what was the point)
     4. limited on-box state makes debugging harder than it should be
     5. failures tend to fan out instead of staying contained

Revocation is also kind of a lie. Just waiting for expiry and hoping that’s good enough.

What actually happens is people reintroduce state anyway: sidecars, caches, agents… because you need it.

We went the opposite direction:

     1. nodes pull over outbound HTTPS
     2. local authorized_keys is the source of truth locally
     3. users/roles are visible on the box
     4. drift fixes itself quickly
     5. no inbound ports, no CA signatures (WELL, not strictly true*!)

You still get central control, but operation and failure modes are local instead of "everyone is locked out right now."

That’s basically what we do at Userify (https://userify.com). Less elegant than certs, more survivable at 2am. Also actually handles authz, not just part of authn.

And the part that usually gets hand-waved with SSH CAs:

     1. creating the user account
     2. managing sudo roles
     3. deciding what happens to home directories on removal
     4. cleanup vs retention for compliance/forensics

Those don’t go away - they're just not part of the certificate solution.

* (TLS still exists here, just at the transport layer using the system trust store. That channel delivers users, keys, and roles. The rest is handled explicitly instead of implied.)

But then you can't log in if your box goes offline for any reason.

We're in the process of updating the experience to this century! ;)

We've always taken the stance that crusty is better than vulnerable, but it turns out that not having a modern experience after 15 years is starting to feel like maybe we need to step up the features and shininess :)

Exactly. We'd had discussions about building https://Userify.com (plug!) around SSH certificates, but elected to go with keys instead, because Userify delivers most of the good things around certificates without the jank and insecurity.

It's not that certificates themselves are insecure themselves, it's that the workflows (as the parent points out) are awful. We might still add some automation around that (and I think I saw some competitor tooling out there if you're committed to that path) but I personally feel like it's an answer to the wrong question.