Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH

> Can you recommend a setup guide?

Depends how far up the chain you want to go (e.g. use step-ca or not), but at the most primitive level, you are looking at something along the following lines of the below (the below is based off my rough notes, I might have missed something).

Note that I have ignored any Yubikey setup considerations here like setting PIN, touch-requirement etc. etc.

I have also assumed plain Yubikey, not the YubiHSM. The YubiHSM comes with SSH certificate signing functionality "out of the box".

Client Yubikey:

   - Use Yubikey ykman[1] to generate a PIV key according to your tastes
   - Grab the key in ssh format with `ssh-keygen -D $path_to/libykcs11 -e > $client_key.pub`

   - Use Yubikey ykman[1] to generate a PIV key according to your tastes
   - Grab the key in ssh format with `ssh-keygen -D $path_to/libykcs11 -e > $issuer_key.pub` (save this for the next step and also put it into your sshd CA config)
   - Sign with the issuer Yubikey with `ssh-keygen -s $issuer_key.pub -D $path_to/libykcs11 -I $whatever_identity -n $principal_list -V +$validity_period $client_key.pub`

[1] https://docs.yubico.com/software/yubikey/tools/ykman/PIV_Com... [2] https://developers.yubico.com/yubico-piv-tool/Releases/

Step CA has some open source parts but it is built in a way where it is inconvenient to use without their admin infra. I also had to do some modifications to their server to make it work properly. If OPKSSH doesn't need all that crap then I am all for it. I'll certainly give it a shot.

Theoretically, is the distinction between IDP and CA necessary? I kinda would expect the IDP to certify my pubkey.

I think it's interesting they're choosing to use certificates this way. If they're already using certs, why not just leverage sshca auth? Also, at the end of the day, it's still effectively a bearer token. I founded a company called Based Security last year in this space. We're looking for design partners currently. We host a CA for you (or you can host yourself if you want) and use ssh certificates and bind the user identity (oidc to the IdP) to a physical device (yubikey, secure enclave, tpm, etc.) This ensures that the user is both in possession of the physical device and that the credential can't be stolen without stealing the device, unlike the bearer token examples here. Currently we're offering support for GitHub and GitLab authentication but it works out of the box with standard ssh tooling as well. It just currently requires manually handling user provisioning for standard ssh access.

> The SSH server now has the secret you used to authenticate with.

secrets can be made unique per connection and single use

This is the purpose of the not so well known audience claim.

Though I'd still prefer to authenticate to something like Vault's SSH engine and get a very short lived SSH certificate instead. No new software to install on your servers, just the CA key.

I'd assume the auth handshake would prevent this.

- client connects to SSH server at IP X.X.X.X or hostname SomeHost

- redirected to oAuth server

- Client signs in and receives token scoped to X.X.X.X or hostname SomeHost

- Client provides token to SSH server

> (Am also not really a fan of having to eventually use a browser for authenticating a terminal session, but that's another problem.)

That sounds awful, I hope this is not the direction we are heading towards.

not just a browser - but coupled with the javascript-as-an-operatingsystem which first assumes you are a bot, but then you prove to it that you are not. lol

I'd love to see the central repository to be breached and tons of computers get new users instantly.

I mean, the idea is nice. There's an alternative implementation being used already in some parts of the world, but their own OIDC provider of their choice.

Decentralization is the key here.

I can neither confirm nor deny the pun is intended.

If you mention Kerberos to most "security" people these days they will think you're talking about Kubernetes.

The problem is, even for large companies, Kerberos can be quite the pain. It's fine for fixed position desktop computers physically located on site or at a remote site with a hardware VPN tunnel - that was what it was built for.

But that is rarely the case any more. People use their own devices (BYOD) that aren't integrated into AD at all, they're using them outside of the office which means there is no VPN available at boot time to deal with token issuance, and the modern "zero trust" crap that uses weird packet filtering black magic instead of proper tun/tap virtual ethernet devices often doesn't play too nice with archaic authentication tools.

On top of that, implementing support for Kerberos in a Dockerized world is just asking for pain.

I like that it's written in a memory-safe language too, but the killer feature is definitely the audit logs.

We keep all this stuff behind WireGuard, which is what I would recommend everybody do.

If you really believe that then help me get the cosigner working with opkssh so even if Google is fully malicious they can't get ssh access.

All the major OpenID Provider want you to use a browser so that users aren't exposing their raw credentials like passwords to an application. We did have an experimental version of this working in a terminal for integration tests a long time ago, but Google views that as malicious behavior and tries to prevent you from doing that. It turns into an arms race with the IdPs.

The good news is you only have to login through the browser once in the morning and then you can use the generated ssh key all day long.

> This does seem to impose the limitation of exactly one client ID per IdP, which could complicate rotating client IDs.

Thanks for asking this. I don't see any reason why you use the same IdP with two different Client-IDs. I haven't tested this, but it is doesn't work currently, I'd like to add it as a feature.

Your description of the protocol is spot on. OpenPubkey currently only works with ID Tokens.

>Is the JWKS response cached? Can it be pre-seeded and/or replaced with an offline copy?

Currently the JWKS response is not cached, but caching support is a feature we want to add.

What is the interest in a pre-seeded copy? Availability concerns?

Excellent, feel free to email me at ethan.r.heilman[at]gmail[]com. Happy to in anyway

Some key differences I observe:

OPKSSH covers only logging in through SSH to an existing user account, while authd covers all forms of login (console, graphical, SSH) and user/group management. The latter makes it much more of a full AAA product rather than just a new way to login with SSH. This means it's a deeper investment, with implications for network file systems (as covered in the docs), while OPKSSH can be added on top of just about any existing infrastructure.

In terms of process, authd uses the Device Authorization Flow to handle logins, which is more vulnerable to phishing. It also requires both sides to have online access to the IdP, whereas the ID token-based approach of OPKSSH allows the authenticating side to have no (*) or limited outbound connectivity. Also, authd seems to support only Microsoft and Google as IdPs right now, whereas OPKSSH (since it builds on OpenPubkey) supports any OpenID Connect IdP.

* = In theory, at least; the current implementation doesn't fully deliver on this, though the one online resource it does need is fairly static and quite cacheable

Thanks for that link, I hadn't heard about this. It looks really cool and I am glad to see ubuntu doing this. I should send ubuntu an email.

Sadly I can not offer an opinion as I don't know how authd works. I intend to find.

You can have multiple trusted CAs which I've found to make rotation a non issue with tooling like Ansible etc.

New CA is minted, public key is added to the accepted list, client signing start using the new CA and you remove the old after a short while.

If missing servers is a common problem it sounds like there are some other fundamental problems outside just authenticated user sessions.

I got this working at one point.

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

You could use `host match exec` instead of `ProxyCommand`. I believe it will run before you end up checking for files on disk.

I didn’t mean to downplay the amount of work involved. It’s just that it feels to me like the ‘solution’ to problems like these seem very simple when that work has been put in.

It’s just that nobody really wants to (OpenID connect became a lot easier to understand when I read the spec, but I never got anywhere close to enjoying it), hence, we didn’t have this until now.