Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.cloudflare.com

Post reply on HN
Print view View original

71–80 of 156 posts

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

#71

Post by kbolino »

deng wrote: post #53
EthanHeilman wrote: post #13

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

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

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

#72

Post by p_l »

rcarmo wrote: post #45
dcow wrote: post #39

Earlier quoted context omitted.

really? that’s a shame kerberos is old and clunky but conceptually it got so much right. I’m so sick of the modern idea that i should wake up and babysit my machine through N different oauth dances to log in to all the services i need on a daily basis. once I authenticate once I should be implicitly authenticated everywhere.

That is one of the things that OIDC sorta almost never really managed to pull off consistently.

One time I actually implemented that on OIDC... by having the OIDC login page do a kerberos login :D

this meant that at most you had a short flash on screen for web apps... which is a bit like OIDC/SAML login on windows domains (but I did it with keycloak back then)

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

#73

Post by EthanHeilman »

kbolino wrote: post #66
EthanHeilman wrote: post #58

Earlier quoted context omitted.

> 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 r…

I can think of two different uses for multiple client IDs with the same IdP: rotation as I mentioned already (e.g. if client secret leaks, although the secret is not used here), and for when there are multiple domains in use but the IdP clients are configured for internal use only. Both are pretty niche though. I think most IdPs will let you keep two client IDs active at the same time, so the rotation use case might…

> 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

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

#74

Post by johnisgood »

rcarmo wrote: post #25
zokier wrote: post #10

I don't love this. > Unfortunately, while ID Tokens do include identity claims like name, organization, and email address, they do not include the user’s public key. This prevents them from being used to directly secure protocols like SSH This seems like dubious statement. SSH authentication does not need to be key based. I understand the practicality of their approach, but I would have preferred this to be proper fi…

Yeah, I don't like this approach either. There was a lot of plumbing added to sshd to support pluggable auth methods, and having used a few of them (including TOTP, for instance), I am not really a fan of "extending" publickey. (Am also not really a fan of having to eventually use a browser for authenticating a terminal session, but that's another problem.)

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

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

#75

Post by out-of-ideas »

rcarmo wrote: post #25
zokier wrote: post #10

I don't love this. > Unfortunately, while ID Tokens do include identity claims like name, organization, and email address, they do not include the user’s public key. This prevents them from being used to directly secure protocols like SSH This seems like dubious statement. SSH authentication does not need to be key based. I understand the practicality of their approach, but I would have preferred this to be proper fi…

Yeah, I don't like this approach either. There was a lot of plumbing added to sshd to support pluggable auth methods, and having used a few of them (including TOTP, for instance), I am not really a fan of "extending" publickey. (Am also not really a fan of having to eventually use a browser for authenticating a terminal session, but that's another problem.)

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

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

#76

Post by tptacek »

This is neat, and more people should be doing things like this. For what it's worth, we use (and like) Teleport, which does certificate-based SSH authentication; an SSO auth gets you a short-lived certificate. It also has the benefits of access control and (most importantly) audit logs; a generic reliable audit log for SSH sessions is a powerful tool to have for compliance stuff, since it transitively gives you an audit log for your CLI tools as well.

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

#77

Post by notTooFarGone »

bayindirh wrote: post #35
notTooFarGone wrote: post #31

Earlier quoted context omitted.

I do love this - everything that makes passwords less used makes the world more secure. Everything that is additionally user friendly has the potential to be the new let's encrypt.

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 lose your root CA certificate you sure are done for too.

Is it better than passwords? 100% - is it perfect? It does not have to be for a lot of use cases.

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

#78

Post by godelski »

I'm not really sure I like SSO and I'm not convinced we should expand this technology. I'm not a security person but most of my concerns aren't actually security either.

My big concern is how we centralize accounts. Not just data access, but like how EVERYTHING is tied to your email. Lose access? You're fucked. Worse, it's very very hard to get support. I'm sure everyone here is well aware of the many horror stories.

Personally I had a bit of a scare when I switched from Android to iPhone. My first iPhone needed to be replaced within 2 weeks and I hadn't gotten everything covered over and not all my 2FAs had transferred to the new phone. Several had to be reset because adding a new 2FA OTP voided the old ones. And since for some reason bitwarden hasn't synched all my notes I had to completely fall back on a few. Which made me glad I didn't force 2FA on all accounts (this is a big fail!!!)

Or even this week, Bitwarden failed on me to provide security keys to sites. The popup would appear but the site had already processed the rejection. Took a few restarts before it was fixed.

The problem I'm seeing here is if we become so dependent on single accounts then this creates a bigger problem than the illness we're trying to solve. While 90% of the time things are better when things go wrong they go nuclear! That's worse!

Yeah, I know with SSO you don't have to use Google/Apple and you can be your own authority. But most people aren't going to do that. Hell, many sites don't even offer anything except Google and Apple! So really we're just setting up a ticking time bomb. It'll be fine for 99% of people 99% of the time, but for the other cases we're making things catastrophic. There's billions of people online so even 1% is a huge number.

Even worse, do we trust these companies will always be around? In your country? To give you proper notice? Do you think you'll even remember everything you need to change? These decisions can be made for you. Even Google accidentally deletes accounts.

So what I really want to see is a system that is more distributed. In the way that we have multiple secure entries. Most methods today are in the form of add 2FA of their choosing and suggest turning off fallback, which is more secure but can fuck you over if it fails. So if we go SSO then this shouldn't replace keys, like the article suggests. Keys are a backup. There should be more too! But then you need to make people occasionally use them to make sure they have that backup. And yes, I understand the more doors there are the bigger attack surface but literally I'm just arguing to not put all our eggs in one basket

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

#79

Post by godelski »

johnisgood wrote: post #74
rcarmo wrote: post #25

Earlier quoted context omitted.

Yeah, I don't like this approach either. There was a lot of plumbing added to sshd to support pluggable auth methods, and having used a few of them (including TOTP, for instance), I am not really a fan of "extending" publickey. (Am also not really a fan of having to eventually use a browser for authenticating a terminal session, but that's another problem.)

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

It happens when there's a cloudflared instance. It is quite annoying

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

#80

Post by EthanHeilman »

godelski wrote: post #78

I'm not really sure I like SSO and I'm not convinced we should expand this technology. I'm not a security person but most of my concerns aren't actually security either. My big concern is how we centralize accounts. Not just data access, but like how EVERYTHING is tied to your email. Lose access? You're fucked. Worse, it's very very hard to get support. I'm sure everyone here is well aware of the many horror stories.…

I work on opkssh and I agree with everything you have just said.

The value of opkssh makes sense in an environment in which already have OpenID Connect as the foundation for identity in your system.

OpenPubkey[0], the protocol opkssh is built on, supports cosigners, which parallel identity attestations. OpenPubkey is currently is designed to use cosigners purely for security, i.e., to remove the IDP as a single point of compromise.

OpenPubkey is built on JSON Web Signatures and JSON Web Signatures can support any number of signers. One could easily extend OpenPubkey to something like, 0x1234 is Alice's public if her public key signed by 7 out of 10 identity cosigners.

What you are describing is the same dream I have: decentralized, secure, human-meaningful names. This is hard to build [1] and you have to start sometime, so I started with the existing identity provider infrastructure but that the beginning. If you are interested in building this future, come work on https://github.com/openpubkey/openpubkey/

[0] OpenPubkey: Augmenting OpenID Connect with User held Signing Keys https://eprint.iacr.org/2023/296

[1] Zooko's triangle is a trilemma of three properties that some people consider desirable for names of participants in a network protocol https://en.wikipedia.org/wiki/Zooko%27s_triangle

Post reply on HN