Author of the blog here and main opkssh contributor. The title is wrong but this is OpenSSH and not a whole new implementation.

opkssh uses the OpenSSH AuthorizedKeysCommand configuration option like AWS instance-connect to add OpenID Connect validation to OpenSSH authentication.

``` opkssh login ```

Generates a valid ssh key in `~/.ssh/`

Then run bog standard ssh or sftp

``` ssh user@hostname ```

ssh will pull this ssh key from `~/.ssh/` and send it to sshd running on your server. If this key isn't in an AuthorizedKeys file sshd will send it to the AuthorizedKeysCommand which if configured to be `opkssh` will check your OpenID Connect credentials.

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...

Excellent point, SSH agent is a feature I've wanted to build for a while now but there was higher priority features. It will probably be included in the next major release. Would you put up for submitting it as a PR?

If I were still using SSH, maybe[1] but I'm thankful that I haven't used SSH in several years. I guess I also dodged a bullet by getting out before the Vault rug pull, since that would have made my life painful

1: although I don't think I'm the target audience for trail-blazing SSH auth; am a much, much bigger fan of just using X509 CA auth using short-term certs; it's much easier to reason about IMHO

OpenPubkey does support X.509 using an X.509 extension.

Out of curiosity, what are you using now? Or do you mean you don't need remote terminals any more because you work on other stuff?

All SSM, all the way. I even gravely considered using their IAM Anywhere capabilities to jump onto Azure or GCP instances, before that project was overcome by events

I'm cheating you a little bit, though, because for the most part once a VM gets kubelet on it, I'm off to the races. Only in very, very, very bad circumstances does getting on the actual Node help me

I also recently have started using <https://docs.aws.amazon.com/systems-manager/latest/userguide...> to even get sequestered cluster access via $(aws ssm start-session --document-name AWS-StartPortForwardingSessionToRemoteHost) although the "bootstrapping" problem of finding the instance-id to feed into --target is a pain. I wish they offered https://docs.aws.amazon.com/systems-manager/latest/userguide... in the spirit of "yeah, yeah, just pick one" versus making me run $(aws ec2 describe-instances --filter | head -n1) type thing

That sounds like an interesting feature to write. Is there an open issue for it?

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...

Just to make sure, opkssh supports OpenID for sftp as well?

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

Tested sftp works and created an integration test for sftp

From the article "OPKSSH does not require any code changes to the SSH server or client."

Looks like this is a sidecar application. So potentially very useful, also potentially very brittle.

It states that it doesn’t require major changes because it all happens under the SSH protocol. A new program is needed on the client to sign in and you can already run a custom program on the server to authorize the key.

I stand corrected. Still not sure I'd want to expose my SSH infrastructure to the massive kludge tower that is OpenID, but it not being its own implementation of the actual SSH protocol is a huge plus.

I imagine it wouldn't be for the system admins to use, it's for all the other users who can use terminal applications but always treat ssh keys as a nuisance and try to avoid them as much as possible.

Lost me at "A new program is needed on the client". Completely.