5 ms·

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 publi

by 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
  - confiq 2y ago
    this ^ GSSAPI can be more secured than public/private key if configured right.
    - dcow 2y ago
      Doesn’t this require the server to consult the IDP on every log in, though, to make sure the id token is valid? One of the staples of ssh from a UX standpoint is that it’s peer to peer.
      - lxgr 2y ago
        I suppose you could do something based on IDP-signed tokens, e.g. "valid for authentication to service x until <timestamp>"?
        megous 2y ago
        This is basically a ssh certificate then.
        pluto_modadic 2y ago
        the difference is in /key management/. Key management is the hard part. Especially keyless SSH management. (things like sigstore's rekor/fulcio remove some complexity here). It is not "just a (manually generated) ssh certificate"
        XorNot 2y ago
        Kerberos tickets have timeouts on them already, it's a matter of configuration how long you wait. The thing is most enterprises want "user disabled" to be instant. Which of course leads to SSH keys all over the place anyway.
    - EthanHeilman 2y ago
      Can you explain more? I want to be a fan of GSSAPI
- _cenw 2y ago
  This is the purpose of the not so well known audience claim. Though I'd still prefer to authenticate to something like Vault's SSH engine and get a very short lived SSH certificate instead. No new software to install on your servers, just the CA key.
  - c45y 2y ago
    CA key also allows those servers to avoid reaching out to some central location to validate which I've found to be a nice side bonus for disaster recovery type scenarios.
    - deleted 2y ago
      [deleted]
- pcthrowaway 2y ago
  I'd assume the auth handshake would prevent this. - client connects to SSH server at IP X.X.X.X or hostname SomeHost - redirected to oAuth server - Client signs in and receives token scoped to X.X.X.X or hostname SomeHost - Client provides token to SSH server
- jrozner 2y ago
  I think it's interesting they're choosing to use certificates this way. If they're already using certs, why not just leverage sshca auth? Also, at the end of the day, it's still effectively a bearer token. I founded a company called Based Security last year in this space. We're looking for design partners currently. We host a CA for you (or you can host yourself if you want) and use ssh certificates and bind the user identity (oidc to the IdP) to a physical device (yubikey, secure enclave, tpm, etc.) This ensures that the user is both in possession of the physical device and that the credential can't be stolen without stealing the device, unlike the bearer token examples here. Currently we're offering support for GitHub and GitLab authentication but it works out of the box with standard ssh tooling as well. It just currently requires manually handling user provisioning for standard ssh access.
  - EthanHeilman 2y ago
    > Why not just leverage sshca auth? Because that has two trusted parties: the IDP and the SSH CA. OPKSSH has just one trusted party: the IDP. > This ensures that the user is both in possession of the physical device and that the credential can't be stolen without stealing the device, unlike the bearer token examples here. Currently we're offering support for GitHub and GitLab authentication but it works out of the box with standard ssh tooling as well. It just currently requires manually handling user provisioning for standard ssh access. That sounds valuable. Have you looked in OpenPubkey, the cosigner protocol supports binding hardware tokens to ID Tokens? Although not as fancy as having the SSH key pair live in the hardware token but maybe we could figure out a way to get the best of both worlds.
    - jrozner 2y ago
      I can understand the concern about having a second trusted party but think that the value of utilizing the standard ssh ca auth flow is worth the potential risk. If you require keys in attested hardware and verify that before issuing certs, the actual attack becomes very difficult. You need to compromise the actual hardware or compromise the CA in a pretty substantial way to issue certs to untrusted private keys. The certificate alone doesn't actually do anything without the key. In addition to just being supported out of the box, we can also issue hardware bound host keys, which allow us to offer bi-directional verification. We gain the benefit of all the standard PKI tooling (eg. revocation lists, ACME, etc.) and can use the same PKI for other scenarios (eg. mTLS, piv, etc.) by issuing x509 certificates instead. That's our long term plan is moving past ssh auth and having it be an attestable, immovable, hardware backed identity that can be usable for continuous authentication in other areas. I have looked into OpenPubKey briefly in the past but haven't spent a ton of time with it. We were going in a very different direction and it didn't seem particularly useful based on our goals or what we wanted to achieve. edit: Looking at the documentation https://docs.bastionzero.com/openpubkey-ssh/openpubkey-ssh/installation-and-deployment https://docs.bastionzero.com/openpubkey-ssh/openpubkey-ssh/i... It seems like to use OpenPubKey you also need a fairly modern version of OpenSSH. It also requires that the user authenticating have sudo access on the machine, which doesn't sound great. It's not clear to me whether it's possible for the existing authorized_keys file to co-exist or whether that's just to stop access using existing keys but using the standard ssh certs will co-exist allowing for a non-binary rollout if there are use cases that need to be worked around.
gfody 2y ago
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
- rcarmo 2y ago
  If you mention Kerberos to most "security" people these days they will think you're talking about Kubernetes.
  - dcow 2y ago
    really? that’s a shame kerberos is old and clunky but conceptually it got so much right. I’m so sick of the modern idea that i should wake up and babysit my machine through N different oauth dances to log in to all the services i need on a daily basis. once I authenticate once I should be implicitly authenticated everywhere.
    - rcarmo 2y ago
      That is one of the things that OIDC sorta almost never really managed to pull off consistently.
      - dcow 2y ago
        And like why not just scrub the `sub` and issue a generic id token (solves idp privacy issues too)… if your service can auth with the claims in the generic token great. if you need more then step up. surely VDCs as a concept have had enough time to mature in the thought space for the industry to be comfortable entertaining this.
      - EthanHeilman 2y ago
        You can do this with OpenPubkey, since the user's client can sign challenges that include the scope of the authentication. Doing this on the web requires being really careful design because you can't trust a javascript client sent to you by the party whose scope you want to control. They could just send you a javascript client that approves a different scope. You still need to do something like the OAuth/OIDC origin-based isolation dance.
rcarmo 2y ago
Yeah, I don't like this approach either. There was a lot of plumbing added to sshd to support pluggable auth methods, and having used a few of them (including TOTP, for instance), I am not really a fan of "extending" publickey. (Am also not really a fan of having to eventually use a browser for authenticating a terminal session, but that's another problem.)
- johnisgood 2y ago
  > (Am also not really a fan of having to eventually use a browser for authenticating a terminal session, but that's another problem.) That sounds awful, I hope this is not the direction we are heading towards.
  - godelski 2y ago
    It happens when there's a cloudflared instance. It is quite annoying
    - johnisgood 2y ago
      That is insane to me. It really requires a browser for a terminal session? No alternatives? Why does it require a browser?
      - godelski 2y ago
        IDK if there was an alternative. But that's how it worked at a previous employer. You'd ssh, a tab would open in your browser, and you'd need to approve the connection. But this doc I found suggests that's my experience is just how it works (very end)[0]. But note that it says legacy (it did not previously when I was using it) [0] https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/use-cases/ssh/ssh-cloudflared-authentication/ https://developers.cloudflare.com/cloudflare-one/connections...
  - cyberax 2y ago
    You can actually have a fully command-line driven Single Sign-On workflow, even anchored in hardware (TouchID, FIDO tokens, etc.) It's not a common way to do it, but it's definitely a possibility.
zokier 2y ago
Googling around I see lot of work around this topic. One example is "Moonshot" project from Janet/Géant and the closely related abfab ietf wg
notTooFarGone 2y ago
I do love this - everything that makes passwords less used makes the world more secure. Everything that is additionally user friendly has the potential to be the new let's encrypt.
- bayindirh 2y ago
  I'd love to see the central repository to be breached and tons of computers get new users instantly. I mean, the idea is nice. There's an alternative implementation being used already in some parts of the world, but their own OIDC provider of their choice. Decentralization is the key here. I can neither confirm nor deny the pun is intended.
  - notTooFarGone 2y ago
    If you lose your root CA certificate you sure are done for too. Is it better than passwords? 100% - is it perfect? It does not have to be for a lot of use cases.
    - bayindirh 2y ago
      Or you can use a local installation with even less risk. See: https://github.com/EOSC-synergy/ssh-oidc https://github.com/EOSC-synergy/ssh-oidc It's not hard to install, and works as advertised, plus it can talk with any OIDC provider your choice, incl. yours.
  - theamk 2y ago
    the central directory in this case is google.com (or github.com, or whatever your OIDC provider is) If it gets breached, there will be significantly more problems than unauthorized ssh login. (and this is a beauty of this compared to something like sshca: there is only one party that you need to trust, and you can choose a party that's unlikely to be breached)
    - deleted 2y ago
      [deleted]
TacticalCoder 2y ago
[dead]

by zokier 2y ago

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
- confiq 2y ago
  this ^ GSSAPI can be more secured than public/private key if configured right.
  - dcow 2y ago
    Doesn’t this require the server to consult the IDP on every log in, though, to make sure the id token is valid? One of the staples of ssh from a UX standpoint is that it’s peer to peer.
    - lxgr 2y ago
      I suppose you could do something based on IDP-signed tokens, e.g. "valid for authentication to service x until <timestamp>"?
      - megous 2y ago
        This is basically a ssh certificate then.
        pluto_modadic 2y ago
        the difference is in /key management/. Key management is the hard part. Especially keyless SSH management. (things like sigstore's rekor/fulcio remove some complexity here). It is not "just a (manually generated) ssh certificate"
      - XorNot 2y ago
        Kerberos tickets have timeouts on them already, it's a matter of configuration how long you wait. The thing is most enterprises want "user disabled" to be instant. Which of course leads to SSH keys all over the place anyway.
  - EthanHeilman 2y ago
    Can you explain more? I want to be a fan of GSSAPI
_cenw 2y ago
This is the purpose of the not so well known audience claim. Though I'd still prefer to authenticate to something like Vault's SSH engine and get a very short lived SSH certificate instead. No new software to install on your servers, just the CA key.
- c45y 2y ago
  CA key also allows those servers to avoid reaching out to some central location to validate which I've found to be a nice side bonus for disaster recovery type scenarios.
  - deleted 2y ago
    [deleted]
pcthrowaway 2y ago
I'd assume the auth handshake would prevent this. - client connects to SSH server at IP X.X.X.X or hostname SomeHost - redirected to oAuth server - Client signs in and receives token scoped to X.X.X.X or hostname SomeHost - Client provides token to SSH server
jrozner 2y ago
I think it's interesting they're choosing to use certificates this way. If they're already using certs, why not just leverage sshca auth? Also, at the end of the day, it's still effectively a bearer token. I founded a company called Based Security last year in this space. We're looking for design partners currently. We host a CA for you (or you can host yourself if you want) and use ssh certificates and bind the user identity (oidc to the IdP) to a physical device (yubikey, secure enclave, tpm, etc.) This ensures that the user is both in possession of the physical device and that the credential can't be stolen without stealing the device, unlike the bearer token examples here. Currently we're offering support for GitHub and GitLab authentication but it works out of the box with standard ssh tooling as well. It just currently requires manually handling user provisioning for standard ssh access.
- EthanHeilman 2y ago
  > Why not just leverage sshca auth? Because that has two trusted parties: the IDP and the SSH CA. OPKSSH has just one trusted party: the IDP. > This ensures that the user is both in possession of the physical device and that the credential can't be stolen without stealing the device, unlike the bearer token examples here. Currently we're offering support for GitHub and GitLab authentication but it works out of the box with standard ssh tooling as well. It just currently requires manually handling user provisioning for standard ssh access. That sounds valuable. Have you looked in OpenPubkey, the cosigner protocol supports binding hardware tokens to ID Tokens? Although not as fancy as having the SSH key pair live in the hardware token but maybe we could figure out a way to get the best of both worlds.
  - jrozner 2y ago
    I can understand the concern about having a second trusted party but think that the value of utilizing the standard ssh ca auth flow is worth the potential risk. If you require keys in attested hardware and verify that before issuing certs, the actual attack becomes very difficult. You need to compromise the actual hardware or compromise the CA in a pretty substantial way to issue certs to untrusted private keys. The certificate alone doesn't actually do anything without the key. In addition to just being supported out of the box, we can also issue hardware bound host keys, which allow us to offer bi-directional verification. We gain the benefit of all the standard PKI tooling (eg. revocation lists, ACME, etc.) and can use the same PKI for other scenarios (eg. mTLS, piv, etc.) by issuing x509 certificates instead. That's our long term plan is moving past ssh auth and having it be an attestable, immovable, hardware backed identity that can be usable for continuous authentication in other areas. I have looked into OpenPubKey briefly in the past but haven't spent a ton of time with it. We were going in a very different direction and it didn't seem particularly useful based on our goals or what we wanted to achieve. edit: Looking at the documentation https://docs.bastionzero.com/openpubkey-ssh/openpubkey-ssh/installation-and-deployment https://docs.bastionzero.com/openpubkey-ssh/openpubkey-ssh/i... It seems like to use OpenPubKey you also need a fairly modern version of OpenSSH. It also requires that the user authenticating have sudo access on the machine, which doesn't sound great. It's not clear to me whether it's possible for the existing authorized_keys file to co-exist or whether that's just to stop access using existing keys but using the standard ssh certs will co-exist allowing for a non-binary rollout if there are use cases that need to be worked around.

gfody 2y ago

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

rcarmo 2y ago
If you mention Kerberos to most "security" people these days they will think you're talking about Kubernetes.
- dcow 2y ago
  really? that’s a shame kerberos is old and clunky but conceptually it got so much right. I’m so sick of the modern idea that i should wake up and babysit my machine through N different oauth dances to log in to all the services i need on a daily basis. once I authenticate once I should be implicitly authenticated everywhere.
  - rcarmo 2y ago
    That is one of the things that OIDC sorta almost never really managed to pull off consistently.
    - dcow 2y ago
      And like why not just scrub the `sub` and issue a generic id token (solves idp privacy issues too)… if your service can auth with the claims in the generic token great. if you need more then step up. surely VDCs as a concept have had enough time to mature in the thought space for the industry to be comfortable entertaining this.
    - EthanHeilman 2y ago
      You can do this with OpenPubkey, since the user's client can sign challenges that include the scope of the authentication. Doing this on the web requires being really careful design because you can't trust a javascript client sent to you by the party whose scope you want to control. They could just send you a javascript client that approves a different scope. You still need to do something like the OAuth/OIDC origin-based isolation dance.

rcarmo 2y ago

Yeah, I don't like this approach either. There was a lot of plumbing added to sshd to support pluggable auth methods, and having used a few of them (including TOTP, for instance), I am not really a fan of "extending" publickey. (Am also not really a fan of having to eventually use a browser for authenticating a terminal session, but that's another problem.)

johnisgood 2y ago
> (Am also not really a fan of having to eventually use a browser for authenticating a terminal session, but that's another problem.) That sounds awful, I hope this is not the direction we are heading towards.
- godelski 2y ago
  It happens when there's a cloudflared instance. It is quite annoying
  - johnisgood 2y ago
    That is insane to me. It really requires a browser for a terminal session? No alternatives? Why does it require a browser?
    - godelski 2y ago
      IDK if there was an alternative. But that's how it worked at a previous employer. You'd ssh, a tab would open in your browser, and you'd need to approve the connection. But this doc I found suggests that's my experience is just how it works (very end)[0]. But note that it says legacy (it did not previously when I was using it) [0] https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/use-cases/ssh/ssh-cloudflared-authentication/ https://developers.cloudflare.com/cloudflare-one/connections...
- cyberax 2y ago
  You can actually have a fully command-line driven Single Sign-On workflow, even anchored in hardware (TouchID, FIDO tokens, etc.) It's not a common way to do it, but it's definitely a possibility.

zokier 2y ago

Googling around I see lot of work around this topic. One example is "Moonshot" project from Janet/Géant and the closely related abfab ietf wg

notTooFarGone 2y ago

I do love this - everything that makes passwords less used makes the world more secure. Everything that is additionally user friendly has the potential to be the new let's encrypt.

bayindirh 2y ago
I'd love to see the central repository to be breached and tons of computers get new users instantly. I mean, the idea is nice. There's an alternative implementation being used already in some parts of the world, but their own OIDC provider of their choice. Decentralization is the key here. I can neither confirm nor deny the pun is intended.
- notTooFarGone 2y ago
  If you lose your root CA certificate you sure are done for too. Is it better than passwords? 100% - is it perfect? It does not have to be for a lot of use cases.
  - bayindirh 2y ago
    Or you can use a local installation with even less risk. See: https://github.com/EOSC-synergy/ssh-oidc https://github.com/EOSC-synergy/ssh-oidc It's not hard to install, and works as advertised, plus it can talk with any OIDC provider your choice, incl. yours.
- theamk 2y ago
  the central directory in this case is google.com (or github.com, or whatever your OIDC provider is) If it gets breached, there will be significantly more problems than unauthorized ssh login. (and this is a beauty of this compared to something like sshca: there is only one party that you need to trust, and you can choose a party that's unlikely to be breached)
  - deleted 2y ago
    [deleted]

TacticalCoder 2y ago

[dead]