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

121–130 of 156 posts

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

#121

Post by theamk »

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.

the central directory in this case is google.com (or github.com, or whatever your OIDC provider is)

If it gets breached, there will be significantly more problems than unauthorized ssh login.

(and this is a beauty of this compared to something like sshca: there is only one party that you need to trust, and you can choose a party that's unlikely to be breached)

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

#122

Post by bradgessler »

I started building an alternative to SSH at https://terminalwire.com that I think is more suitable for one-off commands run on a developer workstation against a SaaS. In more concrete terms, think of the stripe, heroku, and GitHub CLIs.

It’s similar to SSH in that it streams stdio from the server to a thin-client, but that’s where the similarities end. It has additional commands, like open a browser to a URL and set “cookies” on the client terminal from the sever.

When all of those commands are put together, you get something like https://github.com/terminalwire/demodx/blob/main/app/termina... that can open the users browser to an SSO, authorize the CLI, then set a token/nonce/whatever as a “cookie” in the users terminal so they can authenticate and run commands against the SaaS.

My intention isn’t to replace SSH—it’s still the best protocol for a lot of things, but I have found it cumbersome to use it to build CLIs for SaaS, which is why I built Terminalwire.

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

#123

Post by fc417fc802 »

linkregister wrote: post #117
fc417fc802 wrote: post #109

Earlier quoted context omitted.

The browser is also an application. Of course I somehow doubt ELinks will be working with the Google auth page anytime soon. It seems that the goal is to minimize the number of applications into which users view entering their credentials as "normal". The obvious missing piece then is some standardized FOSS project to handle CLI login. Of course that is also unlikely to go over well since what the centralized provide…

I wrote a proprietary variation of this project for a large organization and used a similar approach to the author. The primary reason I used the browser for authentication was to take advantage of FIDO U2F (Yubikeys). Openssh does support U2F authentication, but it requires the user to sign a public key with the hardware device, forcing the organization to again store users' public keys. The users disliked the redir…

> without creating a whole new protocol

Doesn't it "just" require a CLI client that can speak both FIDO U2F and whatever the MFA provider uses? But yeah point taken.

Even if Google and Microsoft don't support it could a FOSS CLI client capable of speaking all the relevant protocols have resolved your issue? With OpenPubkey gaining support it seems to me that a service could potentially support exclusively that and in doing so cover all necessary auth methods simultaneously, at least assuming the provider is comfortable self hosting an IdP solution.

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

#124

Post by Aeolun »

EthanHeilman wrote: post #11
Aeolun wrote: post #7

I think it’s kinda funny that a standard to return a public key in a token, and a server side auth binary that uses that to log you into SSH, are presented here as something groundbreaking. I’m not trying to downplay actually doing it, but it’s been possible since openid connect was invented.

> It’s been possible since openid connect was invented. It has been possible since OpenID Connect was invented but figuring out how to get a public key into an ID Token without having to update IDPs or change the protocol in anyway was not known until we published OpenPubkey[0]. OpenID Connect was not designed to do this. Figuring out how to smuggle this additional information into OpenSSH without requiring code chan…

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.

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

#125

Post by [deleted] »

theamk wrote: post #121
bayindirh wrote: post #35

Earlier quoted context omitted.

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.

the central directory in this case is google.com (or github.com, or whatever your OIDC provider is) If it gets breached, there will be significantly more problems than unauthorized ssh login. (and this is a beauty of this compared to something like sshca: there is only one party that you need to trust, and you can choose a party that's unlikely to be breached)

[deleted]

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

#126

Post by apitman »

EthanHeilman wrote: post #13

Author of the blog post and main opkssh contributor here, happy to answer any questions.

1. Can I use my own indiehosted OP?

2. Looks like this streamlines the server trusting the client. Does it do anything for the client trusting the server? I feel gross saying it, but I almost wonder if we should be moving towards some sort of TLS-based protocol for remote login rather than doubling down on SSH, due to the assurances provided by CAs.

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

#127

Post by teruakohatu »

bradgessler wrote: post #122

I started building an alternative to SSH at https://terminalwire.com that I think is more suitable for one-off commands run on a developer workstation against a SaaS. In more concrete terms, think of the stripe, heroku, and GitHub CLIs. It’s similar to SSH in that it streams stdio from the server to a thin-client, but that’s where the similarities end. It has additional commands, like open a browser to a URL and set…

Interesting. Good luck with it.

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

#128

Post by linkregister »

fc417fc802 wrote: post #123
linkregister wrote: post #117

Earlier quoted context omitted.

I wrote a proprietary variation of this project for a large organization and used a similar approach to the author. The primary reason I used the browser for authentication was to take advantage of FIDO U2F (Yubikeys). Openssh does support U2F authentication, but it requires the user to sign a public key with the hardware device, forcing the organization to again store users' public keys. The users disliked the redir…

> without creating a whole new protocol Doesn't it "just" require a CLI client that can speak both FIDO U2F and whatever the MFA provider uses? But yeah point taken. Even if Google and Microsoft don't support it could a FOSS CLI client capable of speaking all the relevant protocols have resolved your issue? With OpenPubkey gaining support it seems to me that a service could potentially support exclusively that and in…

Indeed I would have preferred to interact with the U2F system libraries, create a challenge-response protocol for the registered U2F device to authenticate, and open source the effort. But I was not skilled enough at pitching the expanded scope. It would have been a more interesting project though!

If I take a sabbatical then writing a client like that sounds interesting. Part of it would be inventing a new MFA provider, as the existing MFA APIs don't expose a "sign with U2F device" authentication method, as far as I know.

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

#130

Post by fc417fc802 »

linkregister wrote: post #128
fc417fc802 wrote: post #123

Earlier quoted context omitted.

> without creating a whole new protocol Doesn't it "just" require a CLI client that can speak both FIDO U2F and whatever the MFA provider uses? But yeah point taken. Even if Google and Microsoft don't support it could a FOSS CLI client capable of speaking all the relevant protocols have resolved your issue? With OpenPubkey gaining support it seems to me that a service could potentially support exclusively that and in…

Indeed I would have preferred to interact with the U2F system libraries, create a challenge-response protocol for the registered U2F device to authenticate, and open source the effort. But I was not skilled enough at pitching the expanded scope. It would have been a more interesting project though! If I take a sabbatical then writing a client like that sounds interesting. Part of it would be inventing a new MFA provi…

At least pocket id and keycloak support fido2/webauthn; I'm sure there are others. I'm not sure how involved a CLI interface for that flow would be though. (Maybe someone has already done it? If so I didn't immediately come across it.)

Keycloak for example provides an API for the password flow. So webauthn via API definitely isn't too far off of what it already provides.

Post reply on HN