Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH
blog.cloudflare.com
OPKSSH (OpenPubkey SSH) is now open-sourced as part of the OpenPubkey project. This enables users and organizations to configure SSH to work with single sign-on technologies like OpenID Connect, removing the need to manually manage & configure SSH keys without adding a trusted party other than your IdP.

My first exposure to this and supposedly just a two line change to the SSH server configuration.

Anyone set this up on their own servers yet? Just for kicks?

  • Xanza@lemm.eeEnglish
    352·
    3 days ago

    I don’t understand the obsession in integrating everything with OID services, like Google. People already complain all the time about Google watch-dogging them and then integrate every single service imaginable with their Google account. Shit is just weird to me.

    • semi [he/him]@lemmy.mlEnglish
      311·
      3 days ago

      I think the Google as an identity provider example is misleading. The more common use case will be medium to small companies where several admins/developers need to login to various servers and where manually adding and revoking keys across these servers will be cumbersome.

      As the other commenter said, in those cases, the organization would also deploy its own IDP.

    • jonathan@lemmy.zipEnglish
      151·
      3 days ago

      Orgs commonly need idp, fuck managing ssh key auth for hundreds of engineers.

      This isn’t aimed at individuals or self-hosters, though you can if you find it interesting enough.

      • corsicanguppy@lemmy.caEnglish
        1·
        2 days ago

        fuck managing ssh key auth for hundreds of engineers.

        You can pull the ssh key out of LDAP/AD. We did this 10 years ago. Really slick.

        Now with modern config management (sit down, Ansible, you millennial junk) the keys update anyway in about a second.

    • farcaller@fstab.shEnglish
      6·
      3 days ago

      I think the point here is moving away from long-lived ssh keys and using whatever IdP you have (enterprise cloud or local oidc) to provide short-term ssh keys. It generally improves the security posture as it’s similar to ssh with certs but less painful to set up.

      • Xanza@lemm.eeEnglish
        1·
        2 days ago

        So does requiring all users to phone you ahead of time to get a temporary password that’s only alive for 20 minutes… But that’s also not done because it’s…stupid.

        There are dozens of tools and methods (like jumpboxes) which facilitate the authorization and usage of currently available and time tested tools for usage with environments without reinventing the wheel. Stepping away from the unix philosophy is heresy of the highest degree.

        It’s not a problem with the tool, only the plumber.

        • surewhynotlem@lemmy.worldEnglish
          2·
          2 days ago

          Stepping away from the unix philosophy

          SSH already allows auth with username and password against a local file. This just moves the file.

    • ladfrombrad 🇬🇧@lemdro.idEnglish
      1·
      3 days ago

      Mine’s having the lazy arse syndrome of using it to sign in to Tailscale and having other friends/family using their SSO from the Big G to simplify them signing into my Tailnet.

      Guilty as charged?

  • Botzo@lemmy.worldEnglish
    4·
    3 days ago

    Definitely looks like a nice improvement. Functions very like cloud provider CLI SSO, but with a generic tool.

    I think for an enterprise use case, supporting the use of the groups claim (or other configurable scopes) is table stakes. Although in those situations, I’ve also had to use other tools like teleport that come with other enterprise niceties like full session audit capture and playback.

    And while everyone should do their own threat and risk modeling, you’ve now made your ssh connection dependent on an external service that likely needs to reach out over the internet.