A better summary. [LWN.net]

A better summary.

Posted Jun 10, 2026 9:55 UTC (Wed) by anselm (subscriber, #2796)
In reply to: A better summary. by LtWorf
Parent article: Eliminating long-lived credentials with trusted publishing

And SSH keys last much longer than 15 minutes, and they're also much easier to find on the disk!

The answer to this is to use short-lived SSH certificates instead of public SSH keys. I don't know whether it will work with Github, but internally we use SSH certificates that last for only 10 hours (or so), issued by a certificate server which authenticates users with OpenID Connect. This means you don't need to copy your public SSH key all over the place, and the corresponding private keys (which users never need to touch) also only last for 10 hours before they become useless to a potential attacker.

to post comments

A better summary.

Posted Jun 11, 2026 13:34 UTC (Thu) by taladar (subscriber, #68407) [Link] (5 responses)

The problem with that approach is of course that you then have an easy single-point of failure added to your system and all to move the credentials the attacker has to steal from the SSH key to the OIDC credentials.

A better summary.

Posted Jun 11, 2026 13:34 UTC (Thu) by taladar (subscriber, #68407) [Link] (4 responses)

Well, or the private signing key of your CA of course, that is another point they could attack to get access to everything.

A better summary.

Posted Jun 12, 2026 7:11 UTC (Fri) by anselm (subscriber, #2796) [Link] (3 responses)

The private signing key of our CA is a lot more difficult to get at than private SSH keys on random developers' laptops, so that's a net win.

Also, access to the OIdC IdP can be straightforwardly made more secure using MFA (e.g., with a USB FIDO2 device). This could of course also be done for standard SSH keys, but it is more of a hassle to set up, it wouldn't solve the problem of having to maintain potentially many copies of the corresponding public SSH keys all over the place, and the USB FIDO2 device works for other web-based services, too.

A better summary.

Posted Jun 12, 2026 7:49 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

BTW, and you also can combine both approaches. Nothing stops you from issuing SSH CA certs for token-based keys.

A better summary.

Posted Jun 12, 2026 16:01 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (1 responses)

I think it's extremely funny that instead of forcing people to use 2FA to do uploads, they forced 2FA to login, and then you create a long lived all-powerful token and forget about 2FA.

I was doing uploads by typing in my password (not stored in any password manager), and now the only way I can do uploads (without moving my projects on a corporate-owned forge) is via a token which sits on my disk, ready to be stolen.

Google gave me an hardware token for free, but it only works for web login.

All of this effort and I'm now less secure than I was a few years ago. Which makes me strongly suspect that ballombe's take is the right one. USA is adding constraints to foreign companies forcing them to avoid any chinese software to be able to sell anything in USA…

A better summary.

Posted Jun 15, 2026 1:27 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

For services with these kinds of things that they're "important" *and* require unencrypted passwords (I've migrated most everything else over to systemd-creds instead now), I instead store the relevant config file as a symlink to an automounted drive that is named through udev/udisks to a stable `/dev/mapper` name.

So, yes, still long-lived, but it doesn't need to be accessible just because I'm logged in (or even just booted as the common case may be).