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

131–140 of 156 posts

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

#131

Post by thyristan »

EthanHeilman wrote: post #34
confiq wrote: post #24

Earlier quoted context omitted.

this ^ GSSAPI can be more secured than public/private key if configured right.

Can you explain more? I want to be a fan of GSSAPI

Don't know what the grandparent meant by GSSAPI, that is just an API for various underlying auth methods. But what people usually use together with GSSAPI is Kerberos.

Kerberos can be very secure, much more so than CA-based or generally asymmetric crypto based approaches. Kerberos (if you ignore some extensions) uses symmetric cryptography, so it is less vulnerable to quantum computers. Use AES256 and you are fine, a quantum attacker can at the most degrade this to a 128bit level (according to current theories). Also, no weak RSA exponents, elliptic curve points at zero, variable-time implementations or other common pitfalls of asymmetric crypto. The trusted third party ("KDC" in Kerberos) distributes keys ("tickets") for pairs of user and service-on-server, so mutual authentication is always assured, not like in ssh or https where you can just ignore that pesky certificate or hostkey error. Keys are short-lived (hours to weeks usually), but there are builtin mechanisms for autorenew if desired. Each side of a key can also be bound to a host identity, so stealing tickets (like cookies in HTTP) can be made harder (but not impossible). The KDC can (theoretically, rarely implemented) also enforce authorisation by preventing users from obtaining tickets for services they are not authorized to use (the original idea of Kerberos was to just use it for authentication, the authorisation step is done by the service after authentication has been established).

Single-Sign-On with all the usual protocols is included automatically, you log in to your workstation and get a ticket-granting-ticket that can then be used to transparently get all the subsequent tickets for services you are using. The hardest one to implement is actually HTTP, because browsers suck and just implement the bare minimum.

However, the whole of Kerberos implementations is ancient, 1990s era software, packed with extensions upon extensions. You don't really want to expose a KDC to the open internet nowadays. The whole thing needs a redesign and rewrite in something safer than 1990s era C.

Oh, and there are mechanisms for federation like trust relationsships between realms and KDCs, but nobody uses those beyond merging internal corporate networks.

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

#132

Post by blueflow »

EthanHeilman wrote: post #57
throw0101c wrote: post #55

Another 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 Open…

Theoretically, is the distinction between IDP and CA necessary? I kinda would expect the IDP to certify my pubkey.

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

#133

Post by traceroute66 »

Whilst this is clearly an interesting development, I still prefer SSH CA backed by hardware on both issuer and client side (e.g. Yubikey).

This is for three reasons:

First, the SSH-CA+Hardware method does not require call-out to third-party code from SSHD, and thus minimises attack surface and attack vectors.

Second, the SSH-CA+Hardware method completely prevents key exfiltration or re-use attacks. Yes, I understand that the SSH keys issued by OPKSSH (or similar tools) are short-lived. But they are still sitting there in your the .ssh directory on your local host, and hence open to exfiltration or re-use. Yes it may be a short-timeframe but much damage can easily be done in a short timeframe, for example exfiltrate key, login, install a backdoor and continue your work via the backdoor.

Finaly, the SSH-CA+Hardware method has fewer moving parts. You don't even need software tools like step-ca. You can do everthing you need with the basic ssh-keygen command. Which means from a sysadmin perspective, perhaps especially sysadmin "emergency break-glass" perspective, you do not need to rely on any third-party services as gatekeeper to your systems.

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

#134

Post by Jnr »

EthanHeilman wrote: post #57
throw0101c wrote: post #55

Another 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 Open…

Step CA has some open source parts but it is built in a way where it is inconvenient to use without their admin infra. I also had to do some modifications to their server to make it work properly. If OPKSSH doesn't need all that crap then I am all for it. I'll certainly give it a shot.

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

#135

Post by Foxboron »

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

You could use `host match exec` instead of `ProxyCommand`. I believe it will run before you end up checking for files on disk.

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

#136

Post by EthanHeilman »

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…

That's awesome. The web needs more terminal interfaces.

What did you use to build that slick explainer video?

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

#137

Post by e40 »

traceroute66 wrote: post #133

Whilst this is clearly an interesting development, I still prefer SSH CA backed by hardware on both issuer and client side (e.g. Yubikey). This is for three reasons: First, the SSH-CA+Hardware method does not require call-out to third-party code from SSHD, and thus minimises attack surface and attack vectors. Second, the SSH-CA+Hardware method completely prevents key exfiltration or re-use attacks. Yes, I understand…

Can you recommend a setup guide?

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

#138

Post by EthanHeilman »

blueflow wrote: post #132
EthanHeilman wrote: post #57

Earlier quoted context omitted.

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

Theoretically, is the distinction between IDP and CA necessary? I kinda would expect the IDP to certify my pubkey.

Currently IDPs don't care about user public keys. OpenPubkey manages to slip the user's public key into an issued ID Token without the IDP having to know about it.

Ideally IDPs are CAs for identity and ID Tokens have a public key field.

There are neat projects and standards to do this like OIDC-squared [0] and OIDC4VC [1] but it is unclear if IDPs will implement them if they are standardized. We do have DPoP now [2] but it isn't available for any of the usecases that are important to me. OpenPubkey is largely an productive expression of my frustration with public keys in tokens being a promised feature that never arrives.

[0]: OIDC-squared https://jonasprimbs.github.io/oidc-squared [1]: OIDC4VC https://identity.foundation/jwt-vc-presentation-profile/ [2]: RFC-9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP) - https://datatracker.ietf.org/doc/html/rfc9449

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

#139

Post by immibis »

mathfailure wrote: post #85
out-of-ideas wrote: post #75

Earlier quoted context omitted.

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

They reject the proofs now: they just show the spinner spinning indefinitely now. CloudFlare is broken and it has widespread so much that it looks like a cancer.

I just get a red circle with a white line across it (a "no entry" traffic sign) and some message paraphrased as "You are a bot, now fuck off, bot."

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

#140

Post by traceroute66 »

e40 wrote: post #137
traceroute66 wrote: post #133

Whilst this is clearly an interesting development, I still prefer SSH CA backed by hardware on both issuer and client side (e.g. Yubikey). This is for three reasons: First, the SSH-CA+Hardware method does not require call-out to third-party code from SSHD, and thus minimises attack surface and attack vectors. Second, the SSH-CA+Hardware method completely prevents key exfiltration or re-use attacks. Yes, I understand…

Can you recommend a setup guide?

> Can you recommend a setup guide?

Depends how far up the chain you want to go (e.g. use step-ca or not), but at the most primitive level, you are looking at something along the following lines of the below (the below is based off my rough notes, I might have missed something).

Note that I have ignored any Yubikey setup considerations here like setting PIN, touch-requirement etc. etc.

I have also assumed plain Yubikey, not the YubiHSM. The YubiHSM comes with SSH certificate signing functionality "out of the box".

Client Yubikey:

   - Use Yubikey ykman[1] to generate a PIV key according to your tastes
   - Grab the key in ssh format with `ssh-keygen -D $path_to/libykcs11 -e > $client_key.pub`
Issuer Yubikey:

   - Use Yubikey ykman[1] to generate a PIV key according to your tastes
   - Grab the key in ssh format with `ssh-keygen -D $path_to/libykcs11 -e > $issuer_key.pub` (save this for the next step and also put it into your sshd CA config)
   - Sign with the issuer Yubikey with `ssh-keygen -s $issuer_key.pub -D $path_to/libykcs11 -I $whatever_identity -n $principal_list -V +$validity_period $client_key.pub`
(libykcs11 is the yubikey library,it ships with yubikey-piv-tool[2])

[1] https://docs.yubico.com/software/yubikey/tools/ykman/PIV_Com... [2] https://developers.yubico.com/yubico-piv-tool/Releases/

==== Edit to add links to various more verbose discussions on the subject (in no particular order):

    - https://liw.fi/sshca/
    - https://goteleport.com/blog/how-to-configure-ssh-certificate-based-authentication/
    - https://jamesog.net/2023/03/03/yubikey-as-an-ssh-certificate-authority/
    - https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-ssh_certificate_pkcs_11_token
Also some verbose discussions on the possibility of doing so with FIDO2. Altough note that the native version of ssh on Apple OS X does not support FIDO2, therefore if you want native Apple support you are best sticking with the PIV method instead.

    - https://developers.yubico.com/SSH/Securing_git_with_SSH_and_FIDO2.html
    - https://medium.com/@harrishcluo/yubikey-ssh-git-super-secure-your-development-workflow-2-2-1899379fb882
    - https://blog.millerti.me/2021/05/16/strengthen-github-ssh-access-with-fido2s-pin-support/
Post reply on HN