9 ms·

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

276 points by PranaFlux 2y ago

RKFADU_UOFCCLEL 2y ago
[flagged]
Hizonner 2y ago
[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.
- asjfkdlf 2y ago
  It states that it doesn’t require major changes because it all happens under the SSH protocol. A new program is needed on the client to sign in and you can already run a custom program on the server to authorize the key.
  - Hizonner 2y ago
    I stand corrected. Still not sure I'd want to expose my SSH infrastructure to the massive kludge tower that is OpenID, but it not being its own implementation of the actual SSH protocol is a huge plus.
    - dugite-code 2y ago
      I imagine it wouldn't be for the system admins to use, it's for all the other users who can use terminal applications but always treat ssh keys as a nuisance and try to avoid them as much as possible.
  - rcarmo 2y ago
    Lost me at "A new program is needed on the client". Completely.
- dugite-code 2y ago
  From the article "OPKSSH does not require any code changes to the SSH server or client." Looks like this is a sidecar application. So potentially very useful, also potentially very brittle.
- EthanHeilman 2y ago
  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 ssh key from `~/.ssh/` and send it to sshd running on your server. If this key isn't in an AuthorizedKeys file sshd will send it to the AuthorizedKeysCommand which if configured to be `opkssh` will check your OpenID Connect credentials.
  - zaat 2y ago
    Just to make sure, opkssh supports OpenID for sftp as well?
    - EthanHeilman 2y ago
      It should, opkssh just creates ssh public keys. The integration tests don't current cover that case so I created an issue to add that to the integration tests: https://github.com/openpubkey/opkssh/issues/40 https://github.com/openpubkey/opkssh/issues/40
    - EthanHeilman 2y ago
      Tested sftp works and created an integration test for sftp
  - mdaniel 2y ago
    I'm surprised it defaults to writing out key material into the filesystem[1] when SSH Agent has existed for quite a while. This use case seems especially relevant to sticking them in the agent given that (IIUC) these are short-lived certs anyway, so if your agent bounced you'd just get a fresh one without drama I do see <https://github.com/openpubkey/opkssh/issues/6#issuecomment-2727546609 https://github.com/openpubkey/opkssh/issues/6#issuecomment-2...> so I'm glad it's conceptually on the radar, I'm just saying I'm surprised it wasn't part of Cloudflare's best practices already 1: https://github.com/openpubkey/opkssh/blob/v0.3.0/commands/login.go#L201 https://github.com/openpubkey/opkssh/blob/v0.3.0/commands/lo...
Aeolun 2y ago
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.
- EthanHeilman 2y ago
  > 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 https://eprint.iacr.org/2023/296
  - Aeolun 2y ago
    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.
    - EthanHeilman 2y ago
      Completely agree. The goal is simple, plain and obvious, but the tools and protocols make it tricky to pull off.
- motoboi 2y ago
znpy 2y ago
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 https://news.ycombinator.com/item?id=43471793). Yep, it's AuthorizedKeysCommand. Good job!
- EthanHeilman 2y ago
  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/ https://github.com/openpubkey/openpubkey/
  - aftbit 2y ago
    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?
    - EthanHeilman 2y ago
      > 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.
zokier 2y ago
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 first-class authentication method instead of smuggling it through publickey auth method. SSH protocol is explicitly designed to support many different auth methods, so this does feel like a missed opportunity. I don't know openssh internals, but could this have been implemented through gssapi? That's the traditional route for ssh sso. If not gssapi, then something similar to it. https://datatracker.ietf.org/doc/html/rfc4462 https://datatracker.ietf.org/doc/html/rfc4462
- EthanHeilman 2y ago
  > 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 https://github.com/francoismichel/ssh3/pull/146
  - slt2021 2y ago
    > The SSH server now has the secret you used to authenticate with. secrets can be made unique per connection and single use
    - 2y ago
EthanHeilman 2y ago
Author of the blog post and main opkssh contributor here, happy to answer any questions.
- notTooFarGone 2y ago
  We are currently struggling with the exact ergonomics of user friendly and secure ssh and I just wanted to say you helped big time here! Will test this for my current use-case and hopefully contribute in the future!
  - EthanHeilman 2y ago
    Excellent, feel free to email me at ethan.r.heilman[at]gmail[]com. Happy to in anyway
- kbolino 2y ago
  This is very interesting! It looks like there's a config file [1] to set up username <- email,issuer associations. It looks like multiple identities (from different IdPs even) can access the same username, which is useful. There's also a config file for allowed IdPs [2] specifying the expected client IDs (btw, the docs here say all fixed duration options are for "24 hours" even 48h and 1week). This does seem to impose the limitation of exactly one client ID per IdP, which could complicate rotating client IDs. 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? [1]: https://github.com/openpubkey/opkssh/blob/main/README.md#etcopkauth_id https://github.com/openpubkey/opkssh/blob/main/README.md#etc... [2]: https://github.com/openpubkey/opkssh/blob/main/README.md#etcopkproviders https://github.com/openpubkey/opkssh/blob/main/README.md#etc...
  - EthanHeilman 2y ago
    > 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 response cached? Can it be pre-seeded and/or replaced with an offline copy? Currently the JWKS response is not cached, but caching support is a feature we want to add. What is the interest in a pre-seeded copy? Availability concerns?
deleted 2y ago
[deleted]
samcat116 2y ago
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.
- EthanHeilman 2y ago
  The benefits of this is that you don't have the attack surface of an SSH CA. If you do this with an SSH CA that supports OIDC, if either the IDP or the SSH CA are compromised then security is lost. With OpenPubkey and by extension opkssh, your IDP is functioning like the SSH CA by signing the public key that you make the SSH connection with. Thus, you have one fewer trusted party and you don't have maintain and secure an SSH CA. Beyond this, rotating SSH CAs is hard because you need to put the public key of the SSH CA on each SSH server and SSH certs don't support intermediate certificates. Thus if you SSH CA is hacked, you need to update the CA public key on all your servers and hope you don't miss any. OpenID Connect IDPs rotate their public keys often and if they get hacked and they can immediately rotate their public keys without any update to relying servers.
  - c45y 2y ago
    You can have multiple trusted CAs which I've found to make rotation a non issue with tooling like Ansible etc. New CA is minted, public key is added to the accepted list, client signing start using the new CA and you remove the old after a short while. If missing servers is a common problem it sounds like there are some other fundamental problems outside just authenticated user sessions.
    - EthanHeilman 2y ago
      That's smart! You could probably automate that using a cron job pulling the latest CA public keys so servers automatically rotates CA public keys every few days. > If missing servers is a common problem it sounds like there are some other fundamental problems outside just authenticated user sessions. On one hand yes, on the other hand that is just the current reality in large enterprises. Consider this quote from Tatu Ylonen's (Inventor of SSH) recent paper [0] “In many organizations – even very security-conscious organizations – there are many times more obsolete authorized keys than they have employees. Worse, authorized keys generally grant command-line shell access, which in itself is often considered privileged. We have found that in many organizations about 10% of the authorized keys grant root or administrator access. SSH keys never expire.” If authorized keys get missed, servers are going to get missed. opkssh was partially inspired by the challenges presented in this paper. [0]: Challenges in Managing SSH Keys – and a Call for Solutions https://ylonen.org/papers/ssh-key-challenges.pdf https://ylonen.org/papers/ssh-key-challenges.pdf
ciaovietnam 2y ago
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.
- bayindirh 2y ago
  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 https://github.com/EOSC-synergy/ssh-oidc
  - EthanHeilman 2y ago
    That's neat, I've added it to my reading list.
- EthanHeilman 2y ago
  OpenPubkey is software and opensource. All software has vulnerabilities but we aren't a service or SaaS or anything.
naikrovek 2y ago
I swear to god people make things more complex solely because they plan to yank these things out from under us later.
atonse 2y ago
How does this compare to Tailscale SSH? Will the two eventually be combined in some way? I think tailscale SSH requires you to run their daemon on the server, correct?
- EthanHeilman 2y ago
  When I looked at this previous Tailscale required two trusted parties. I haven't looked at the tailscale protocol details in two years so maybe it has changed.
throw0101c 2y ago
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-ca/provisioners/#oauthoidc-single-sign-on https://smallstep.com/docs/step-ca/provisioners/#oauthoidc-s... as well as cloud providers: * https://smallstep.com/docs/step-ca/provisioners/#cloud-provisioners https://smallstep.com/docs/step-ca/provisioners/#cloud-provi... There are commercial offerings as well: * https://www.google.com/search?q=centrally+managed+ssh+certificates https://www.google.com/search?q=centrally+managed+ssh+certif...
- EthanHeilman 2y ago
  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 OpenPubkey protocol
  - blueflow 2y ago
    Theoretically, is the distinction between IDP and CA necessary? I kinda would expect the IDP to certify my pubkey.
    - EthanHeilman 2y ago
      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 https://jonasprimbs.github.io/oidc-squared [1]: OIDC4VC https://identity.foundation/jwt-vc-presentation-profile/ 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 https://datatracker.ietf.org/doc/html/rfc9449
jmclnx 2y ago
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 https://undeadly.org and no mention of anything like this. FWIW, I will never use this.
- EthanHeilman 2y ago
  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.
deleted 2y ago
[deleted]
kipz 2y ago
FWIW, I think this is really cool! I'm going to give it a spin!
tptacek 2y ago
This is neat, and more people should be doing things like this. For what it's worth, we use (and like) Teleport, which does certificate-based SSH authentication; an SSO auth gets you a short-lived certificate. It also has the benefits of access control and (most importantly) audit logs; a generic reliable audit log for SSH sessions is a powerful tool to have for compliance stuff, since it transitively gives you an audit log for your CLI tools as well.
- antman 2y ago
  The open source version supports only GitHub SSO, is that your provider?
- EthanHeilman 2y ago
  Is audit logs and access control the main features that would convince you to use Teleport vs something like opkssh? How important is the VPN functionality that lets you get packets to private IPs?
  - tptacek 2y ago
    I like that it's written in a memory-safe language too, but the killer feature is definitely the audit logs. We keep all this stuff behind WireGuard, which is what I would recommend everybody do.
    - atonse 2y ago
      We use Tailscale for our WireGuard, which further integrates with SSO. So it’s a double whammy. But Tailscale ssh has the identity stuff built in too.
godelski 2y ago
I'm not really sure I like SSO and I'm not convinced we should expand this technology. I'm not a security person but most of my concerns aren't actually security either. My big concern is how we centralize accounts. Not just data access, but like how EVERYTHING is tied to your email. Lose access? You're fucked. Worse, it's very very hard to get support. I'm sure everyone here is well aware of the many horror stories. Personally I had a bit of a scare when I switched from Android to iPhone. My first iPhone needed to be replaced within 2 weeks and I hadn't gotten everything covered over and not all my 2FAs had transferred to the new phone. Several had to be reset because adding a new 2FA OTP voided the old ones. And since for some reason bitwarden hasn't synched all my notes I had to completely fall back on a few. Which made me glad I didn't force 2FA on all accounts (this is a big fail!!!) Or even this week, Bitwarden failed on me to provide security keys to sites. The popup would appear but the site had already processed the rejection. Took a few restarts before it was fixed. The problem I'm seeing here is if we become so dependent on single accounts then this creates a bigger problem than the illness we're trying to solve. While 90% of the time things are better when things go wrong they go nuclear! That's worse! Yeah, I know with SSO you don't have to use Google/Apple and you can be your own authority. But most people aren't going to do that. Hell, many sites don't even offer anything except Google and Apple! So really we're just setting up a ticking time bomb. It'll be fine for 99% of people 99% of the time, but for the other cases we're making things catastrophic. There's billions of people online so even 1% is a huge number. Even worse, do we trust these companies will always be around? In your country? To give you proper notice? Do you think you'll even remember everything you need to change? These decisions can be made for you. Even Google accidentally deletes accounts. So what I really want to see is a system that is more distributed. In the way that we have multiple secure entries. Most methods today are in the form of add 2FA of their choosing and suggest turning off fallback, which is more secure but can fuck you over if it fails. So if we go SSO then this shouldn't replace keys, like the article suggests. Keys are a backup. There should be more too! But then you need to make people occasionally use them to make sure they have that backup. And yes, I understand the more doors there are the bigger attack surface but literally I'm just arguing to not put all our eggs in one basket
- EthanHeilman 2y ago
  I work on opkssh and I agree with everything you have just said. The value of opkssh makes sense in an environment in which already have OpenID Connect as the foundation for identity in your system. OpenPubkey[0], the protocol opkssh is built on, supports cosigners, which parallel identity attestations. OpenPubkey is currently is designed to use cosigners purely for security, i.e., to remove the IDP as a single point of compromise. OpenPubkey is built on JSON Web Signatures and JSON Web Signatures can support any number of signers. One could easily extend OpenPubkey to something like, 0x1234 is Alice's public if her public key signed by 7 out of 10 identity cosigners. What you are describing is the same dream I have: decentralized, secure, human-meaningful names. This is hard to build [1] and you have to start sometime, so I started with the existing identity provider infrastructure but that the beginning. If you are interested in building this future, come work on https://github.com/openpubkey/openpubkey/ https://github.com/openpubkey/openpubkey/ [0] OpenPubkey: Augmenting OpenID Connect with User held Signing Keys https://eprint.iacr.org/2023/296 https://eprint.iacr.org/2023/296 [1] Zooko's triangle is a trilemma of three properties that some people consider desirable for names of participants in a network protocol https://en.wikipedia.org/wiki/Zooko%27s_triangle https://en.wikipedia.org/wiki/Zooko%27s_triangle
bzmrgonz 2y ago
has this project been audited tho? Because it seems to me we are shifting the authentication process to opkssh, so the question then becomes, how secure is the code-build?
_hyn3 2y ago
How does this compare to Userify's plain-jane SSH key technique? That agent (Python, single-file https://github.com/userify/shim https://github.com/userify/shim) sticks with decentralized regular keys and only centralizes the control plane, which seems to be more reliable in case your auth server goes offline - you can still login to your servers (obviously no new users or updates to existing keys). It just automates user and sudo configuration using things like adduser and /etc/sudoers.d. (It also actively kills user sessions and removes the user account when they're deleted, which is great for when you're walking someone out in case they have cron-jobs or a long-running tmux session with a revenge script.) This project looks powerful but with a lot of heavy dependencies, which seem like an increased surface area (like Userify's Active Directory integration, but at least that's optional)
- nullc 2y ago
  I believe the idea of this scheme is so that the NSA tailored access operations staff embedded in organizations such as google and cloudflare can authorize access without having to individually intercept each server (or jumphost) you own. You benefit from more reliable shipping delivery times, no more mysterious city-of-industry->ftmeade->sanfrancisco detours or hardware that fails prematurely due to uncleaned flux or whiskers from implant installations.
  - EthanHeilman 2y ago
    If you really believe that then help me get the cosigner working with opkssh so even if Google is fully malicious they can't get ssh access.
notorandit 2y ago
Yet another tool on top of other ones. Let's hope no backdoor will be added there.
password4321 2y ago
Semi-related OpenSSH fork supporting auth with X.509 certificate CA: https://roumenpetrov.info/secsh/ https://roumenpetrov.info/secsh/ And a walkthrough (2020): http://tech.ciges.net/blog/openssh-with-x509-certificates-how-to/ http://tech.ciges.net/blog/openssh-with-x509-certificates-ho...
somat 2y ago
Fair enough, I can see how this would be useful but I have to admit I was hoping it would be the opposite, how to log into a web page with a ssh key.
bradgessler 2y ago
I started building an alternative to SSH at https://terminalwire.com 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/terminal/main_terminal/authorization_commands.rb 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.
- teruakohatu 2y ago
  Interesting. Good luck with it.
- EthanHeilman 2y ago
  That's awesome. The web needs more terminal interfaces. What did you use to build that slick explainer video?
  - bradgessler 2y ago
    Screen Studio for macOS
    - EthanHeilman 2y ago
      Do you recommend it? How easy is it to edit videos and add overlays and images? I've been looking for something to record demos of opkssh. What I have now isn't cutting it.
      - 2y ago
dizhn 2y ago
I like that they used (and abused) standard ssh server features to implement this. Is anybody aware of something like this that can be automated for things like ansible or see a way to use this there?
- EthanHeilman 2y ago
  > Is anybody aware of something like this that can be automated for things like ansible Doesn't ansible already get you all of this? What is the feature gap you are looking to fill? That said you definitely use opkssh in automation. OpenPubkey already supports the github-action and gitlab-CI OpenID Providers so in theory you could use opkssh to let a github-action or gitlab-CI workflow ssh into servers under that workflows identity. That is, have a policy on your SSH server that allows only "workflows from repo X triggered by a merge into main ...". Additionally you can always do machine-identity using OpenID Connect either by running your own JWKS server. While this works in OpenPubkey, we haven't added this to opkssh yet but we have an issue for it. If you want support for this add your usecase as a comment https://github.com/openpubkey/opkssh/issues/51 https://github.com/openpubkey/opkssh/issues/51
  - dizhn 2y ago
    As far as I understand, this solution requires interactive authentication first, i.e it brings up the idp login page then issues the required keys etc. I was asking about whether there's a way to automate this such that one can use a static token, or a machine key etc. This way you could still benefit from rotating the key, cancelling a user's access etc. I believe this is what sssd can do today except it doesn't work on musl based distros.
traceroute66 2y ago
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.
- e40 2y ago
  Can you recommend a setup guide?
  - traceroute66 2y ago
    > 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_Commands.html https://docs.yubico.com/software/yubikey/tools/ykman/PIV_Com... [2] https://developers.yubico.com/yubico-piv-tool/Releases/ 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/
cjcampbell 2y ago
Definitely interested to kick the tires and compare to some of the other solutions out there. As others mentioned, you lose some benefits of an OIDC-integrated SSH CA, but that’s a reasonable trade off in order to reduce complexity for many use cases. A missing piece of the puzzle for me is general OSS tooling to provision the Linux OS users. While it works in some environments to grant multiple parties access to the same underlying OS users, it’s necessary (or at least easier) in others to have users accessed named user accounts. Step-ca makes good use of NSS/PAM to make this seamless when attached to a smallstep account (which can be backed by an IdP and provisioned through SCIM). While I could stand up LDAP to accommodate this use case, I’d love a lightweight way for a couple of servers to source users directly from the most popular IdP APIs. I get by with a script that syncs a group every N minutes. And while that’s more than sufficient for a couple of these use cases, I’ll own up to wanting the shiny thing and the same elegance of step-ca’s tooling.

276 points by PranaFlux 2y ago

[flagged]

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

asjfkdlf 2y ago
It states that it doesn’t require major changes because it all happens under the SSH protocol. A new program is needed on the client to sign in and you can already run a custom program on the server to authorize the key.
- Hizonner 2y ago
  I stand corrected. Still not sure I'd want to expose my SSH infrastructure to the massive kludge tower that is OpenID, but it not being its own implementation of the actual SSH protocol is a huge plus.
  - dugite-code 2y ago
    I imagine it wouldn't be for the system admins to use, it's for all the other users who can use terminal applications but always treat ssh keys as a nuisance and try to avoid them as much as possible.
- rcarmo 2y ago
  Lost me at "A new program is needed on the client". Completely.
dugite-code 2y ago
From the article "OPKSSH does not require any code changes to the SSH server or client." Looks like this is a sidecar application. So potentially very useful, also potentially very brittle.
EthanHeilman 2y ago
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 ssh key from `~/.ssh/` and send it to sshd running on your server. If this key isn't in an AuthorizedKeys file sshd will send it to the AuthorizedKeysCommand which if configured to be `opkssh` will check your OpenID Connect credentials.
- zaat 2y ago
  Just to make sure, opkssh supports OpenID for sftp as well?
  - EthanHeilman 2y ago
    It should, opkssh just creates ssh public keys. The integration tests don't current cover that case so I created an issue to add that to the integration tests: https://github.com/openpubkey/opkssh/issues/40 https://github.com/openpubkey/opkssh/issues/40
  - EthanHeilman 2y ago
    Tested sftp works and created an integration test for sftp
- mdaniel 2y ago
  I'm surprised it defaults to writing out key material into the filesystem[1] when SSH Agent has existed for quite a while. This use case seems especially relevant to sticking them in the agent given that (IIUC) these are short-lived certs anyway, so if your agent bounced you'd just get a fresh one without drama I do see <https://github.com/openpubkey/opkssh/issues/6#issuecomment-2727546609 https://github.com/openpubkey/opkssh/issues/6#issuecomment-2...> so I'm glad it's conceptually on the radar, I'm just saying I'm surprised it wasn't part of Cloudflare's best practices already 1: https://github.com/openpubkey/opkssh/blob/v0.3.0/commands/login.go#L201 https://github.com/openpubkey/opkssh/blob/v0.3.0/commands/lo...

Aeolun 2y ago

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.

EthanHeilman 2y ago
> 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 https://eprint.iacr.org/2023/296
- Aeolun 2y ago
  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.
  - EthanHeilman 2y ago
    Completely agree. The goal is simple, plain and obvious, but the tools and protocols make it tricky to pull off.
motoboi 2y ago

znpy 2y ago

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 https://news.ycombinator.com/item?id=43471793). Yep, it's AuthorizedKeysCommand. Good job!

EthanHeilman 2y ago
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/ https://github.com/openpubkey/openpubkey/
- aftbit 2y ago
  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?
  - EthanHeilman 2y ago
    > 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.

zokier 2y ago

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 first-class authentication method instead of smuggling it through publickey auth method. SSH protocol is explicitly designed to support many different auth methods, so this does feel like a missed opportunity. I don't know openssh internals, but could this have been implemented through gssapi? That's the traditional route for ssh sso. If not gssapi, then something similar to it. https://datatracker.ietf.org/doc/html/rfc4462 https://datatracker.ietf.org/doc/html/rfc4462

EthanHeilman 2y ago
> 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 https://github.com/francoismichel/ssh3/pull/146
- slt2021 2y ago
  > The SSH server now has the secret you used to authenticate with. secrets can be made unique per connection and single use
  - 2y ago

EthanHeilman 2y ago

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

notTooFarGone 2y ago
We are currently struggling with the exact ergonomics of user friendly and secure ssh and I just wanted to say you helped big time here! Will test this for my current use-case and hopefully contribute in the future!
- EthanHeilman 2y ago
  Excellent, feel free to email me at ethan.r.heilman[at]gmail[]com. Happy to in anyway
kbolino 2y ago
This is very interesting! It looks like there's a config file [1] to set up username <- email,issuer associations. It looks like multiple identities (from different IdPs even) can access the same username, which is useful. There's also a config file for allowed IdPs [2] specifying the expected client IDs (btw, the docs here say all fixed duration options are for "24 hours" even 48h and 1week). This does seem to impose the limitation of exactly one client ID per IdP, which could complicate rotating client IDs. 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? [1]: https://github.com/openpubkey/opkssh/blob/main/README.md#etcopkauth_id https://github.com/openpubkey/opkssh/blob/main/README.md#etc... [2]: https://github.com/openpubkey/opkssh/blob/main/README.md#etcopkproviders https://github.com/openpubkey/opkssh/blob/main/README.md#etc...
- EthanHeilman 2y ago
  > 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 response cached? Can it be pre-seeded and/or replaced with an offline copy? Currently the JWKS response is not cached, but caching support is a feature we want to add. What is the interest in a pre-seeded copy? Availability concerns?

deleted 2y ago

[deleted]

samcat116 2y ago

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.

EthanHeilman 2y ago
The benefits of this is that you don't have the attack surface of an SSH CA. If you do this with an SSH CA that supports OIDC, if either the IDP or the SSH CA are compromised then security is lost. With OpenPubkey and by extension opkssh, your IDP is functioning like the SSH CA by signing the public key that you make the SSH connection with. Thus, you have one fewer trusted party and you don't have maintain and secure an SSH CA. Beyond this, rotating SSH CAs is hard because you need to put the public key of the SSH CA on each SSH server and SSH certs don't support intermediate certificates. Thus if you SSH CA is hacked, you need to update the CA public key on all your servers and hope you don't miss any. OpenID Connect IDPs rotate their public keys often and if they get hacked and they can immediately rotate their public keys without any update to relying servers.
- c45y 2y ago
  You can have multiple trusted CAs which I've found to make rotation a non issue with tooling like Ansible etc. New CA is minted, public key is added to the accepted list, client signing start using the new CA and you remove the old after a short while. If missing servers is a common problem it sounds like there are some other fundamental problems outside just authenticated user sessions.
  - EthanHeilman 2y ago
    That's smart! You could probably automate that using a cron job pulling the latest CA public keys so servers automatically rotates CA public keys every few days. > If missing servers is a common problem it sounds like there are some other fundamental problems outside just authenticated user sessions. On one hand yes, on the other hand that is just the current reality in large enterprises. Consider this quote from Tatu Ylonen's (Inventor of SSH) recent paper [0] “In many organizations – even very security-conscious organizations – there are many times more obsolete authorized keys than they have employees. Worse, authorized keys generally grant command-line shell access, which in itself is often considered privileged. We have found that in many organizations about 10% of the authorized keys grant root or administrator access. SSH keys never expire.” If authorized keys get missed, servers are going to get missed. opkssh was partially inspired by the challenges presented in this paper. [0]: Challenges in Managing SSH Keys – and a Call for Solutions https://ylonen.org/papers/ssh-key-challenges.pdf https://ylonen.org/papers/ssh-key-challenges.pdf

ciaovietnam 2y ago

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.

bayindirh 2y ago
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 https://github.com/EOSC-synergy/ssh-oidc
- EthanHeilman 2y ago
  That's neat, I've added it to my reading list.
EthanHeilman 2y ago
OpenPubkey is software and opensource. All software has vulnerabilities but we aren't a service or SaaS or anything.

naikrovek 2y ago

I swear to god people make things more complex solely because they plan to yank these things out from under us later.

atonse 2y ago

How does this compare to Tailscale SSH? Will the two eventually be combined in some way? I think tailscale SSH requires you to run their daemon on the server, correct?

EthanHeilman 2y ago
When I looked at this previous Tailscale required two trusted parties. I haven't looked at the tailscale protocol details in two years so maybe it has changed.

throw0101c 2y ago

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-ca/provisioners/#oauthoidc-single-sign-on https://smallstep.com/docs/step-ca/provisioners/#oauthoidc-s... as well as cloud providers: * https://smallstep.com/docs/step-ca/provisioners/#cloud-provisioners https://smallstep.com/docs/step-ca/provisioners/#cloud-provi... There are commercial offerings as well: * https://www.google.com/search?q=centrally+managed+ssh+certificates https://www.google.com/search?q=centrally+managed+ssh+certif...

EthanHeilman 2y ago
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 OpenPubkey protocol
- blueflow 2y ago
  Theoretically, is the distinction between IDP and CA necessary? I kinda would expect the IDP to certify my pubkey.
  - EthanHeilman 2y ago
    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 https://jonasprimbs.github.io/oidc-squared [1]: OIDC4VC https://identity.foundation/jwt-vc-presentation-profile/ 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 https://datatracker.ietf.org/doc/html/rfc9449

jmclnx 2y ago

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 https://undeadly.org and no mention of anything like this. FWIW, I will never use this.

EthanHeilman 2y ago
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.

deleted 2y ago

[deleted]

kipz 2y ago

FWIW, I think this is really cool! I'm going to give it a spin!

tptacek 2y ago

This is neat, and more people should be doing things like this. For what it's worth, we use (and like) Teleport, which does certificate-based SSH authentication; an SSO auth gets you a short-lived certificate. It also has the benefits of access control and (most importantly) audit logs; a generic reliable audit log for SSH sessions is a powerful tool to have for compliance stuff, since it transitively gives you an audit log for your CLI tools as well.

antman 2y ago
The open source version supports only GitHub SSO, is that your provider?
EthanHeilman 2y ago
Is audit logs and access control the main features that would convince you to use Teleport vs something like opkssh? How important is the VPN functionality that lets you get packets to private IPs?
- tptacek 2y ago
  I like that it's written in a memory-safe language too, but the killer feature is definitely the audit logs. We keep all this stuff behind WireGuard, which is what I would recommend everybody do.
  - atonse 2y ago
    We use Tailscale for our WireGuard, which further integrates with SSO. So it’s a double whammy. But Tailscale ssh has the identity stuff built in too.

godelski 2y ago

I'm not really sure I like SSO and I'm not convinced we should expand this technology. I'm not a security person but most of my concerns aren't actually security either. My big concern is how we centralize accounts. Not just data access, but like how EVERYTHING is tied to your email. Lose access? You're fucked. Worse, it's very very hard to get support. I'm sure everyone here is well aware of the many horror stories. Personally I had a bit of a scare when I switched from Android to iPhone. My first iPhone needed to be replaced within 2 weeks and I hadn't gotten everything covered over and not all my 2FAs had transferred to the new phone. Several had to be reset because adding a new 2FA OTP voided the old ones. And since for some reason bitwarden hasn't synched all my notes I had to completely fall back on a few. Which made me glad I didn't force 2FA on all accounts (this is a big fail!!!) Or even this week, Bitwarden failed on me to provide security keys to sites. The popup would appear but the site had already processed the rejection. Took a few restarts before it was fixed. The problem I'm seeing here is if we become so dependent on single accounts then this creates a bigger problem than the illness we're trying to solve. While 90% of the time things are better when things go wrong they go nuclear! That's worse! Yeah, I know with SSO you don't have to use Google/Apple and you can be your own authority. But most people aren't going to do that. Hell, many sites don't even offer anything except Google and Apple! So really we're just setting up a ticking time bomb. It'll be fine for 99% of people 99% of the time, but for the other cases we're making things catastrophic. There's billions of people online so even 1% is a huge number. Even worse, do we trust these companies will always be around? In your country? To give you proper notice? Do you think you'll even remember everything you need to change? These decisions can be made for you. Even Google accidentally deletes accounts. So what I really want to see is a system that is more distributed. In the way that we have multiple secure entries. Most methods today are in the form of add 2FA of their choosing and suggest turning off fallback, which is more secure but can fuck you over if it fails. So if we go SSO then this shouldn't replace keys, like the article suggests. Keys are a backup. There should be more too! But then you need to make people occasionally use them to make sure they have that backup. And yes, I understand the more doors there are the bigger attack surface but literally I'm just arguing to not put all our eggs in one basket

EthanHeilman 2y ago
I work on opkssh and I agree with everything you have just said. The value of opkssh makes sense in an environment in which already have OpenID Connect as the foundation for identity in your system. OpenPubkey[0], the protocol opkssh is built on, supports cosigners, which parallel identity attestations. OpenPubkey is currently is designed to use cosigners purely for security, i.e., to remove the IDP as a single point of compromise. OpenPubkey is built on JSON Web Signatures and JSON Web Signatures can support any number of signers. One could easily extend OpenPubkey to something like, 0x1234 is Alice's public if her public key signed by 7 out of 10 identity cosigners. What you are describing is the same dream I have: decentralized, secure, human-meaningful names. This is hard to build [1] and you have to start sometime, so I started with the existing identity provider infrastructure but that the beginning. If you are interested in building this future, come work on https://github.com/openpubkey/openpubkey/ https://github.com/openpubkey/openpubkey/ [0] OpenPubkey: Augmenting OpenID Connect with User held Signing Keys https://eprint.iacr.org/2023/296 https://eprint.iacr.org/2023/296 [1] Zooko's triangle is a trilemma of three properties that some people consider desirable for names of participants in a network protocol https://en.wikipedia.org/wiki/Zooko%27s_triangle https://en.wikipedia.org/wiki/Zooko%27s_triangle

bzmrgonz 2y ago

has this project been audited tho? Because it seems to me we are shifting the authentication process to opkssh, so the question then becomes, how secure is the code-build?

_hyn3 2y ago

How does this compare to Userify's plain-jane SSH key technique? That agent (Python, single-file https://github.com/userify/shim https://github.com/userify/shim) sticks with decentralized regular keys and only centralizes the control plane, which seems to be more reliable in case your auth server goes offline - you can still login to your servers (obviously no new users or updates to existing keys). It just automates user and sudo configuration using things like adduser and /etc/sudoers.d. (It also actively kills user sessions and removes the user account when they're deleted, which is great for when you're walking someone out in case they have cron-jobs or a long-running tmux session with a revenge script.) This project looks powerful but with a lot of heavy dependencies, which seem like an increased surface area (like Userify's Active Directory integration, but at least that's optional)

nullc 2y ago
I believe the idea of this scheme is so that the NSA tailored access operations staff embedded in organizations such as google and cloudflare can authorize access without having to individually intercept each server (or jumphost) you own. You benefit from more reliable shipping delivery times, no more mysterious city-of-industry->ftmeade->sanfrancisco detours or hardware that fails prematurely due to uncleaned flux or whiskers from implant installations.
- EthanHeilman 2y ago
  If you really believe that then help me get the cosigner working with opkssh so even if Google is fully malicious they can't get ssh access.

notorandit 2y ago

Yet another tool on top of other ones. Let's hope no backdoor will be added there.

password4321 2y ago

Semi-related OpenSSH fork supporting auth with X.509 certificate CA: https://roumenpetrov.info/secsh/ https://roumenpetrov.info/secsh/ And a walkthrough (2020): http://tech.ciges.net/blog/openssh-with-x509-certificates-how-to/ http://tech.ciges.net/blog/openssh-with-x509-certificates-ho...

somat 2y ago

Fair enough, I can see how this would be useful but I have to admit I was hoping it would be the opposite, how to log into a web page with a ssh key.

bradgessler 2y ago

I started building an alternative to SSH at https://terminalwire.com 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/terminal/main_terminal/authorization_commands.rb 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.

teruakohatu 2y ago
Interesting. Good luck with it.
EthanHeilman 2y ago
That's awesome. The web needs more terminal interfaces. What did you use to build that slick explainer video?
- bradgessler 2y ago
  Screen Studio for macOS
  - EthanHeilman 2y ago
    Do you recommend it? How easy is it to edit videos and add overlays and images? I've been looking for something to record demos of opkssh. What I have now isn't cutting it.
    - 2y ago

dizhn 2y ago

I like that they used (and abused) standard ssh server features to implement this. Is anybody aware of something like this that can be automated for things like ansible or see a way to use this there?

EthanHeilman 2y ago
> Is anybody aware of something like this that can be automated for things like ansible Doesn't ansible already get you all of this? What is the feature gap you are looking to fill? That said you definitely use opkssh in automation. OpenPubkey already supports the github-action and gitlab-CI OpenID Providers so in theory you could use opkssh to let a github-action or gitlab-CI workflow ssh into servers under that workflows identity. That is, have a policy on your SSH server that allows only "workflows from repo X triggered by a merge into main ...". Additionally you can always do machine-identity using OpenID Connect either by running your own JWKS server. While this works in OpenPubkey, we haven't added this to opkssh yet but we have an issue for it. If you want support for this add your usecase as a comment https://github.com/openpubkey/opkssh/issues/51 https://github.com/openpubkey/opkssh/issues/51
- dizhn 2y ago
  As far as I understand, this solution requires interactive authentication first, i.e it brings up the idp login page then issues the required keys etc. I was asking about whether there's a way to automate this such that one can use a static token, or a machine key etc. This way you could still benefit from rotating the key, cancelling a user's access etc. I believe this is what sssd can do today except it doesn't work on musl based distros.

traceroute66 2y ago

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.

e40 2y ago
Can you recommend a setup guide?
- traceroute66 2y ago
  > 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_Commands.html https://docs.yubico.com/software/yubikey/tools/ykman/PIV_Com... [2] https://developers.yubico.com/yubico-piv-tool/Releases/ 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/

cjcampbell 2y ago

Definitely interested to kick the tires and compare to some of the other solutions out there. As others mentioned, you lose some benefits of an OIDC-integrated SSH CA, but that’s a reasonable trade off in order to reduce complexity for many use cases. A missing piece of the puzzle for me is general OSS tooling to provision the Linux OS users. While it works in some environments to grant multiple parties access to the same underlying OS users, it’s necessary (or at least easier) in others to have users accessed named user accounts. Step-ca makes good use of NSS/PAM to make this seamless when attached to a smallstep account (which can be backed by an IdP and provisioned through SCIM). While I could stand up LDAP to accommodate this use case, I’d love a lightweight way for a couple of servers to source users directly from the most popular IdP APIs. I get by with a script that syncs a group every N minutes. And while that’s more than sufficient for a couple of these use cases, I’ll own up to wanting the shiny thing and the same elegance of step-ca’s tooling.