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

11–20 of 156 posts

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

#11

Post by EthanHeilman »

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 changes or adding a SSH CA required a significant amount of work. I could be wrong but as far as I am aware the combined use of smuggling data in SSH public keys with AuthorizedKeyCommand to validate that data was not done until opkssh.

This was three years of careful work of reading through OpenID Connect specs, SSH RFCs, reading OpenSSH source code to get this to be fully compatible with existing IDPs and OpenSSH.

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

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

#12

Post by motoboi »

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.

Openid is just a bunch of http requests and browser redirects, if you think about it.

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

#14

Post by EthanHeilman »

znpy wrote: post #9

People could already cook up something similar using AuthorizedKeysCommand and similar. As long as you can upload some kind of key to an external system (eg: short-lived ssh certificate) you can then query that certificate via AuthorizedKeysCommand. Edit: just saw the comment by the author of the post ( https://news.ycombinator.com/item?id=43471793 ). Yep, it's AuthorizedKeysCommand. Good job!

I gotta say, I love AuthorizedKeysCommand, it is the most clever configuration option I've seen in a protocol!

If you just try to stuff a ID Token into an SSH key and use AuthorizedKeysCommands you introduce replay attacks because the SSH server can pull your ID Token out and stuff it into another SSH key and replay it to other SSH servers to impersonate you. Opkssh doesn't have this weakness because it used OpenPubkey [0].

The real trick here is OpenPubkey. OpenID Connect gives you ID Tokens which don't contain public keys. OpenPubkey tricks your OpenID Connect IDP into including a public key you choose in the ID Token it issues. This turns ID Tokens into certificates without requiring any changes to the IDP. This makes ID Tokens safe to use in SSH.

[0]: https://github.com/openpubkey/openpubkey/

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

#15

Post by aftbit »

EthanHeilman wrote: post #14
znpy wrote: post #9

People could already cook up something similar using AuthorizedKeysCommand and similar. As long as you can upload some kind of key to an external system (eg: short-lived ssh certificate) you can then query that certificate via AuthorizedKeysCommand. Edit: just saw the comment by the author of the post ( https://news.ycombinator.com/item?id=43471793 ). Yep, it's AuthorizedKeysCommand. Good job!

I gotta say, I love AuthorizedKeysCommand, it is the most clever configuration option I've seen in a protocol! If you just try to stuff a ID Token into an SSH key and use AuthorizedKeysCommands you introduce replay attacks because the SSH server can pull your ID Token out and stuff it into another SSH key and replay it to other SSH servers to impersonate you. Opkssh doesn't have this weakness because it used OpenPubk…

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?

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

#16

Post by EthanHeilman »

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…

> This seems like dubious statement. SSH authentication does not need to be key based.

Let's say you just use an ID Token as a bearer token to authenticate to SSH. The SSH server now has the secret you used to authenticate with. Doesn't this introduce replay attacks where the SSH server can replay your ID Token to log into other SSH servers?

Whereas if your ID Token functions like a "certificate" issued by your IDP binding your identity to a public key, it is no longer a secret. You can just use your public key to prove you are you. No secrets leave your computer.

My motto: always use public key rather than a bearer secret if possible.

> I understand the practicality of their approach, but I would have preferred this to be proper first-class authentication method instead of smuggling it through publickey auth method

Me too. I have a PR open to SSH3 (not connected with OpenSSH) so it can be support OpenPubkey as a built-in authentication mechanism.

https://github.com/francoismichel/ssh3/pull/146

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

#17

Post by gfody »

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…

ssh -k is too enterprise for ̶t̶e̶c̶h̶b̶r̶o̶ ̶s̶t̶a̶r̶t̶u̶p̶s̶ small companies that don't want to setup a kerberos realm

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

#18

Post by zaat »

EthanHeilman wrote: post #8
Hizonner wrote: post #2

[Note on edit: this is wrong] ... apparently in the form of a whole new implementation. Not realistic. If it's not in OpenSSH, it effectively doesn't exist.

Author of the blog here and main opkssh contributor. The title is wrong but this is OpenSSH and not a whole new implementation. opkssh uses the OpenSSH AuthorizedKeysCommand configuration option like AWS instance-connect to add OpenID Connect validation to OpenSSH authentication. ``` opkssh login ``` Generates a valid ssh key in `~/.ssh/` Then run bog standard ssh or sftp ``` ssh user@hostname ``` ssh will pull this…

Just to make sure, opkssh supports OpenID for sftp as well?

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

#19

Post by slt2021 »

EthanHeilman wrote: post #16
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…

> This seems like dubious statement. SSH authentication does not need to be key based. Let's say you just use an ID Token as a bearer token to authenticate to SSH. The SSH server now has the secret you used to authenticate with. Doesn't this introduce replay attacks where the SSH server can replay your ID Token to log into other SSH servers? Whereas if your ID Token functions like a "certificate" issued by your IDP b…

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

secrets can be made unique per connection and single use

Post reply on HN