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

61–70 of 156 posts

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

#61

Post by EthanHeilman »

radlad wrote: post #36
samcat116 wrote: post #21

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.

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

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

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

#62

Post by EthanHeilman »

aftbit wrote: post #52
EthanHeilman wrote: post #44

Earlier quoted context omitted.

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

No, the SSH server only learns your public key and a signature specific to the SSH server generated in the SSH handshake. A malicious server would need your private key to successfully authenticate to another SSH server.

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

#63

Post by EthanHeilman »

mdaniel wrote: post #49
EthanHeilman wrote: post #47

Earlier quoted context omitted.

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.

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

#64

Post by EthanHeilman »

bayindirh wrote: post #32
ciaovietnam wrote: post #30

Now I have to trust OpenPubkey, hoping it wont get hacked. No way will I add this to my servers, I will keep using the long live public key.

If you want to roll your own, here's another implementation which people already use, with their own OpenID Connect infrastructures. You can deploy and use in a completely closed system. https://github.com/EOSC-synergy/ssh-oidc

That's neat, I've added it to my reading list.

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

#65

Post by EthanHeilman »

jmclnx wrote: post #56

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

It is not a patch. It doesn't require any code changes to OpenSSH.

opkssh uses AuthorizedKeysCommand field in sshd_config. OpenBSD added this config field to OpenSSH to enable people to do stuff like opkssh or instance-connect without needing to do code patches. OpenSSH is really smart about enabling functionality like this via the config.

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

#66

Post by kbolino »

EthanHeilman wrote: post #58
kbolino wrote: post #50

Earlier quoted context omitted.

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 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 already be covered.

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). Completely offline JWKS would also be useful for machines with no outbound connectivity. Both use cases are again pretty niche though.

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

#69

Post by dcow »

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.

And like why not just scrub the `sub` and issue a generic id token (solves idp privacy issues too)… if your service can auth with the claims in the generic token great. if you need more then step up. surely VDCs as a concept have had enough time to mature in the thought space for the industry to be comfortable entertaining this.

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

#70

Post by EthanHeilman »

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.

You can do this with OpenPubkey, since the user's client can sign challenges that include the scope of the authentication.

Doing this on the web requires being really careful design because you can't trust a javascript client sent to you by the party whose scope you want to control. They could just send you a javascript client that approves a different scope. You still need to do something like the OAuth/OIDC origin-based isolation dance.

Post reply on HN