How does this compare to Tailscale SSH? Will the two eventually be combined in some way?
I think tailscale SSH requires you to run their daemon on the server, correct?
Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH
51–60 of 156 posts
Re: Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH
#52Earlier quoted context omitted.
How does this prevent replay attacks, either by a malicious SSH server proxying the auth flow from another machine, or by a malicious server pulling out the signed IdP claims and passing them to another OpenID Connect target?
> a malicious server pulling out the signed IdP claims and passing them to another OpenID Connect target The signed IdP claims aren't a secret. In OpenPubkey, they function like certificate for the user's public key. This makes them useless for replay attacks in opkssh. The signed IdP claims are also scoped to a Client-ID specific for opkssh, so non-opkssh OpenID Connect services will reject them.
Sure, but couldn't a malicious SSH server use this key to proxy a connection to another opkssh server?
Re: Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH
#53Author of the blog post and main opkssh contributor here, happy to answer any questions.
What would you say is the advantage of this approach over integrating OIDC into a separate service, like what Ubuntu is trying with authd?
(see https://ubuntu.com/blog/authd-oidc-authentication-for-ubuntu...)
Re: Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH
#54Earlier quoted context omitted.
this ^ GSSAPI can be more secured than public/private key if configured right.
Doesn’t this require the server to consult the IDP on every log in, though, to make sure the id token is valid? One of the staples of ssh from a UX standpoint is that it’s peer to peer.
I suppose you could do something based on IDP-signed tokens, e.g. "valid for authentication to service x until "?
Re: Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH
#55Another option:
SSH certificates have been around for a while now, so you can create an in-house SSH CA, so that they are short-lived (compared to on-laptop keys) and you have to authenticate to get a fresh one.
To automate getting SSH certs there are a number of options, including the step-ca project, which can talk to OAUTH/OIDC systems (Google, Okta, Microsoft Entra ID, Keycloak):
* https://smallstep.com/docs/step-ca/provisioners/#oauthoidc-s...
as well as cloud providers:
* https://smallstep.com/docs/step-ca/provisioners/#cloud-provi...
There are commercial offerings as well:
* https://www.google.com/search?q=centrally+managed+ssh+certif...
Re: Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH
#56Looks like yet another patch to OpenSSH that the OpenBSD people will stay away from as far as the can. What can go wrong ?
At least that is my belief, do people here think my speculation is correct ? I checked https://undeadly.org and no mention of anything like this.
FWIW, I will never use this.
Re: Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH
#57Another option: SSH certificates have been around for a while now, so you can create an in-house SSH CA, so that they are short-lived (compared to on-laptop keys) and you have to authenticate to get a fresh one. To automate getting SSH certs there are a number of options, including the step-ca project, which can talk to OAUTH/OIDC systems (Google, Okta, Microsoft Entra ID, Keycloak): * https://smallstep.com/docs/step…
Step-ca is really cool and has a lot of templating and policy stuff opkssh doesn't currently have. However step-ca does require two trusted parties: your IDP and the SSH CA.
The advantage of opkssh is that there is only one trusted party, your IDP.
While not available in opkssh yet, OpenPubkey even has a way of removing the trust assumption in your IDP.
I wonder if step-ca would ever consider using opkssh or the OpenPubkey protocol
Re: Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH
#58Author of the blog post and main opkssh contributor here, happy to answer any questions.
This is very interesting! It looks like there's a config file [1] to set up username 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…
> 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?
Re: Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH
#59Author of the blog post and main opkssh contributor here, happy to answer any questions.
What would you say is the advantage of this approach over integrating OIDC into a separate service, like what Ubuntu is trying with authd? (see https://ubuntu.com/blog/authd-oidc-authentication-for-ubuntu... )
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.
Re: Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH
#60How does this compare to Tailscale SSH? Will the two eventually be combined in some way? I think tailscale SSH requires you to run their daemon on the server, correct?
When I looked at this previous Tailscale required two trusted parties. I haven't looked at the tailscale protocol details in two years so maybe it has changed.