HNHacker News
TopNewBestAskShowJobs

jamiesonbecker

459 karma · joined August 22, 2018

CEO at Swarm Research Labs, formerly of Popchat

biased heavily in favour of AI (and little tech in general) Email: first at https://hunterswarm.com https://X.com/JamiesonBecker https://LinkedIn.com/in/JamiesonBecker

submissionscomments
jamiesonbecker··on The Ubuntu 26.04 Rust sudo is not compatible with standard sudo
> I do not really have words for this. The Rust sudo has apparently opted to keep the single most dangerous wildcard while disallowing all of the wildcards that allow one to be narrow and specific about what you're allowing, and it buries this at the end of a section that devotes a bunch of words to describing functionality it doesn't have and doesn't support, with absolutely nothing else in that section to say this (either up front or in the descriptions of how all the wildcards would work if sudo-rs supported them, which it doesn't).

> Also, this is documentation calculated to mislead busy system administrators who are skimming it to see if there is some big difference between the Rust sudo that Canonical has stuck them with and the real version of sudo.

just.. wow.

jamiesonbecker··on The Ubuntu 26.04 Rust sudo is not compatible with standard sudo
would Userify solve that need for you? old but reliable
jamiesonbecker··on DeepSeek banned from U.S. federal civilian agencies under new DHS order
> 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.

jamiesonbecker··on DeepSeek banned from U.S. federal civilian agencies under new DHS order
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-...
jamiesonbecker··on DeepSeek banned from U.S. federal civilian agencies under new DHS order
> 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.

jamiesonbecker··on China Plans to Tighten Export Controls on AI Technologies
> 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?

jamiesonbecker··on Namecheap just seized and disabled all my domains
EasyDNS
jamiesonbecker··on Google is silently linking your phone number across all signed-in accounts
Very unexpected behavior, esp for those with several accounts and phone numbers, intending to keep them separate for security or other reasons.
jamiesonbecker··on Self-hosted HTTP tunnels with SSH and Nginx
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.

jamiesonbecker··on Self-hosted HTTP tunnels with SSH and Nginx
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

jamiesonbecker··on I switched to Brave
See also Brave Origin: https://brave.com/origin/
jamiesonbecker··on Socialism's Positive Rating Tops 40% for First Time
It's Russia 1917 or Cuba 1959 all over again.

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

jamiesonbecker··on Flock is rolling out a voluntary severance program
I ran back to grab my towel, but my house was getting bulldozed.
jamiesonbecker··on Show HN: Cactus Needle 3: 8-29MB automation models can match DeepSeek V4 Flash
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.

jamiesonbecker··on We got admin access to Baseten's production GitHub in 25 minutes
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.

jamiesonbecker··on Show HN: Moadim.io – A scheduler for agents
`crontab -e` and add:

  # at 3am every day.. 
  * * * 3 0   cd ~/src; claude -p "find and fix bugs and commit"
jamiesonbecker··on Put your SSH keys in your TPM chip
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.

jamiesonbecker··on Put your SSH keys in your TPM chip
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.

jamiesonbecker··on NanoClaw's architecture is a masterclass in doing less
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.

jamiesonbecker··on SSH certificates: the better SSH experience
Then install your own:

    curl i.userify.com | sudo - sE
jamiesonbecker··on SSH certificates: the better SSH experience
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.)
jamiesonbecker··on SSH certificates: the better SSH experience
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.

jamiesonbecker··on SSH certificates: the better SSH experience
Great question. Not yet ;)
jamiesonbecker··on SSH certificates: the better SSH experience
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.

jamiesonbecker··on SSH certificates: the better SSH experience
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.

jamiesonbecker··on SSH certificates: the better SSH experience
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.)

jamiesonbecker··on SSH certificates: the better SSH experience
But then you can't log in if your box goes offline for any reason.
jamiesonbecker··on SSH certificates: the better SSH experience
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 :)

jamiesonbecker··on SSH certificates: the better SSH experience
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.

jamiesonbecker··on Disable Your SSH access accidentally with scp
Classic OpenSSH safety check: if /home/$user (or ~/.ssh) is too open, or ownership/modes are off, sshd will refuse pubkey auth. Annoying, but correct.

If you still have some access (console, password login, another sudo user), this usually fixes it:

    username=bob
    sudo chown "$username:$username" /home/$username
    sudo chmod 700 /home/$username

    sudo install -d -m 700 -o "$username" -g "$username" /home/$username/.ssh
    echo "ssh-ed25519 AAAA....insertyourpubkeyhere" | sudo tee /home/$username/.ssh/authorized_keys >/dev/null
    sudo chown "$username:$username" /home/$username/.ssh/authorized_keys
    sudo chmod 600 /home/$username/.ssh/authorized_keys
(optional, if the user needs sudo)

    echo "$username ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/$username >/dev/null
    sudo chmod 440 /etc/sudoers.d/$username
Not to shill too hard, but this exact "keys/perms/sudo drift" failure mode is why Userify exists (est. 2011): local accounts on every box + a tiny outbound-only agent that polls and overwrites desired state (keys, perms, sudo role). If scp/rsync/deploy steps clobber stuff, the next poll re-converges it (cloud default ~90s; self-host default ~10s; configurable). Removing a user also kills their sessions. No inbound ports to nodes, no PAM/NSS hooks, auditable.

Shim (old but readable): https://github.com/userify/shim/blob/master/shim.py#L308 (obligatory): https://userify.com

Page 1 of 24Next →