I can't tell the benefits of this vs running an SSH CA that supports OIDC. In that scenario, the server just needs to trust the CAs key, rather than running some sort of verifier.
The benefits of this is that you don't have the attack surface of an SSH CA. If you do this with an SSH CA that supports OIDC, if either the IDP or the SSH CA are compromised then security is lost.
With OpenPubkey and by extension opkssh, your IDP is functioning like the SSH CA by signing the public key that you make the SSH connection with. Thus, you have one fewer trusted party and you don't have maintain and secure an SSH CA.
Beyond this, rotating SSH CAs is hard because you need to put the public key of the SSH CA on each SSH server and SSH certs don't support intermediate certificates. Thus if you SSH CA is hacked, you need to update the CA public key on all your servers and hope you don't miss any. OpenID Connect IDPs rotate their public keys often and if they get hacked and they can immediately rotate their public keys without any update to relying servers.
That's smart! You could probably automate that using a cron job pulling the latest CA public keys so servers automatically rotates CA public keys every few days.
> If missing servers is a common problem it sounds like there are some other fundamental problems outside just authenticated user sessions.
On one hand yes, on the other hand that is just the current reality in large enterprises. Consider this quote from Tatu Ylonen's (Inventor of SSH) recent paper [0]
“In many organizations – even very security-conscious organizations – there are many times more obsolete authorized keys than they have employees. Worse, authorized keys generally grant command-line shell access, which in itself is often considered privileged. We have found that in many organizations about 10% of the authorized keys grant root or administrator access. SSH keys never expire.”
If authorized keys get missed, servers are going to get missed.
opkssh was partially inspired by the challenges presented in this paper.
Years ago, I tried building something like this using ProxyCommand to try to fetch the SSH certificate "just-in-time" without having to run a command first, but unfortunately the ordering of OpenSSH was such that ProxyCommand ran after checking the disk for SSH certs/keys. :(
The trick is to use your SSH config to intercept SSH connections so the got to a local SSH server, this triggers ProxyCommand and let's you create the cert and then forward those packets into an outgoing SSH connection you don't intercept.
SSH --> Local SSH Server --> ProxyCommand (create cert) --> SSH --> Remote SSH Server
I’ve played a bit with this, but iirc, I ran into limitations with some of the clients that needed to be supported. But if all you need is OpenSSH, you should be set.
