opkssh

opkssh (https://github.com/openpubkey/opkssh) it lets you configure OpenSSH so you can ssh using your OpenID Connect identity without adding a trusted party other than the IDP. I'm trying to figure out how to TOFU a MFA HW token (yubikey) on first login so we don't even have to trust the IDP. The trick part is to design so if you lose your HW Token you aren't locked out without reintroducing trust. Maybe use a backup code or backup yubikey or the DKIM trick to allow timelocked resets of the HW Token via an email.

> Is anybody aware of something like this that can be automated for things like ansible Doesn't ansible already get you all of this? What is the feature gap you are looking to fill? That said you definitely use opkssh in automation. OpenPubkey already supports the github-action and gitlab-CI OpenID Providers so in theory you could use opkssh to let a github-action or gitlab-CI workflow ssh into servers under that workflows identity. That is, have a policy on your SSH server that allows only "workflows from repo X triggered by a merge into main ...". Additionally you can always do machine-identity using OpenID Connect either by running your own JWKS server. While this works in OpenPubkey, we haven't added this to opkssh yet but we have an issue for it. If you want support for this add your usecase as a comment https://github.com/openpubkey

There is an issue with a lively discussion happening currently "Key management improvements on the client and SSH agent support": https://github.com/openpubkey/opkssh/issues/6#issuecomment-2...

> As for pre-seeded/offline JWKS, yeah the biggest concern is around availability. The pre-seeded case would handle fresh VM setups before networking might be fully configured (though other auth methods as fallback would be good enough in most cases, I think). I've been thinking about this as breakglass problem. How do you get into your server if your IDP is offline or you lose internet connectivity. My recommendation has been to have a standard public key SSH account breakglass. A pre-seeded JWKS or alternative JWKS would let you have the same policy controls but allow you to create valid keys in extreme circumstances. I really like this. I created an issue to track this. Let me knof you want to do the implementation https://github.com/openpubkey/opkssh/issues/44

This is very interesting! It looks like there's a config file [1] to set up username <- email,issuer associations. It looks like multiple identities (from different IdPs even) can access the same username, which is useful. There's also a config file for allowed IdPs [2] specifying the expected client IDs (btw, the docs here say all fixed duration options are for "24 hours" even 48h and 1week). This does seem to impose the limitation of exactly one client ID per IdP, which could complicate rotating client IDs. Walking this through, given that OpenID Connect is specifically mentioned vs. bare OAuth2, I assume the ID token signatures are themselves verified by looking up ${ISSUER_URI}/.well-known/openid-configuration and following the jwks_uri found there. Is the JWKS response cached? Can it be pre-seeded and/or replaced with an offline copy

It should, opkssh just creates ssh public keys. The integration tests don't current cover that case so I created an issue to add that to the integration tests: https://github.com/openpubkey/opkssh/issues/40

I'm surprised it defaults to writing out key material into the filesystem[1] when SSH Agent has existed for quite a while. This use case seems especially relevant to sticking them in the agent given that (IIUC) these are short-lived certs anyway, so if your agent bounced you'd just get a fresh one without drama I do see <https://github.com/openpubkey/opkssh/issues/6#issuecomment-2...> so I'm glad it's conceptually on the radar, I'm just saying I'm surprised it wasn't part of Cloudflare's best practices already 1: https://github.com/openpubkey/opkssh/blob/v0.3.0/commands/lo...