6 ms·

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?
  - kbolino 2y ago
    I can think of two different uses for multiple client IDs with the same IdP: rotation as I mentioned already (e.g. if client secret leaks, although the secret is not used here), and for when there are multiple domains in use but the IdP clients are configured for internal use only. Both are pretty niche though. I think most IdPs will let you keep two client IDs active at the same time, so the rotation use case might already be covered. As for pre-seeded/offline JWKS, yeah the biggest concern is around availability. The pre-seeded case would handle fresh VM setups before networking might be fully configured (though other auth methods as fallback would be good enough in most cases, I think). Completely offline JWKS would also be useful for machines with no outbound connectivity. Both use cases are again pretty niche though.
    - EthanHeilman 2y ago
      > As for pre-seeded/offline JWKS, yeah the biggest concern is around availability. The pre-seeded case would handle fresh VM setups before networking might be fully configured (though other auth methods as fallback would be good enough in most cases, I think). I've been thinking about this as breakglass problem. How do you get into your server if your IDP is offline or you lose internet connectivity. My recommendation has been to have a standard public key SSH account breakglass. A pre-seeded JWKS or alternative JWKS would let you have the same policy controls but allow you to create valid keys in extreme circumstances. I really like this. I created an issue to track this. Let me knof you want to do the implementation https://github.com/openpubkey/opkssh/issues/44 https://github.com/openpubkey/opkssh/issues/44
deng 2y ago
What would you say is the advantage of this approach over integrating OIDC into a separate service, like what Ubuntu is trying with authd? (see https://ubuntu.com/blog/authd-oidc-authentication-for-ubuntu-desktop-server https://ubuntu.com/blog/authd-oidc-authentication-for-ubuntu...)
- EthanHeilman 2y ago
  Thanks for that link, I hadn't heard about this. It looks really cool and I am glad to see ubuntu doing this. I should send ubuntu an email. Sadly I can not offer an opinion as I don't know how authd works. I intend to find.
- kbolino 2y ago
  Some key differences I observe: OPKSSH covers only logging in through SSH to an existing user account, while authd covers all forms of login (console, graphical, SSH) and user/group management. The latter makes it much more of a full AAA product rather than just a new way to login with SSH. This means it's a deeper investment, with implications for network file systems (as covered in the docs), while OPKSSH can be added on top of just about any existing infrastructure. In terms of process, authd uses the Device Authorization Flow to handle logins, which is more vulnerable to phishing. It also requires both sides to have online access to the IdP, whereas the ID token-based approach of OPKSSH allows the authenticating side to have no (*) or limited outbound connectivity. Also, authd seems to support only Microsoft and Google as IdPs right now, whereas OPKSSH (since it builds on OpenPubkey) supports any OpenID Connect IdP. * = In theory, at least; the current implementation doesn't fully deliver on this, though the one online resource it does need is fairly static and quite cacheable
ale42 2y ago
The idea of using SSO for SSH sounds interesting for some applications, but does the login process really need to be browser-based? Can't we just have the login prompt in the terminal (without needing to run a headless browser behind-the-scenes of course)? I'm often working on headless machines, and other devices that definitely don't have a browser installed, and it would be pretty painful to use (not to mention that when working in a terminal, I find very annoying to have to switch to a browser, or to any other window by the way).
- EthanHeilman 2y ago
  All the major OpenID Provider want you to use a browser so that users aren't exposing their raw credentials like passwords to an application. We did have an experimental version of this working in a terminal for integration tests a long time ago, but Google views that as malicious behavior and tries to prevent you from doing that. It turns into an arms race with the IdPs. The good news is you only have to login through the browser once in the morning and then you can use the generated ssh key all day long.
  - fc417fc802 2y ago
    The browser is also an application. Of course I somehow doubt ELinks will be working with the Google auth page anytime soon. It seems that the goal is to minimize the number of applications into which users view entering their credentials as "normal". The obvious missing piece then is some standardized FOSS project to handle CLI login. Of course that is also unlikely to go over well since what the centralized providers actually want (which is fundamentally incompatible with user freedoms) is attestation. Arbitrarily blessing a few browser implementations that are extremely difficult to compile on your own is just a roundabout method to approximate that (IMO anyway). Edit: It seems like a mistake to me to conflate anit-phishing efforts and IdP. Anti-phishing should be via hardware tokens or TOTP or whatever. IdP should be about large corporations managing user accounts or about individuals gaining convenience, including by serving as an adapter so that the latest popular standard can be used without each downstream service needing to adopt it.
    - 2y ago
apitman 2y ago
1. Can I use my own indiehosted OP? 2. Looks like this streamlines the server trusting the client. Does it do anything for the client trusting the server? I feel gross saying it, but I almost wonder if we should be moving towards some sort of TLS-based protocol for remote login rather than doubling down on SSH, due to the assurances provided by CAs.

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?
- kbolino 2y ago
  I can think of two different uses for multiple client IDs with the same IdP: rotation as I mentioned already (e.g. if client secret leaks, although the secret is not used here), and for when there are multiple domains in use but the IdP clients are configured for internal use only. Both are pretty niche though. I think most IdPs will let you keep two client IDs active at the same time, so the rotation use case might already be covered. As for pre-seeded/offline JWKS, yeah the biggest concern is around availability. The pre-seeded case would handle fresh VM setups before networking might be fully configured (though other auth methods as fallback would be good enough in most cases, I think). Completely offline JWKS would also be useful for machines with no outbound connectivity. Both use cases are again pretty niche though.
  - EthanHeilman 2y ago
    > As for pre-seeded/offline JWKS, yeah the biggest concern is around availability. The pre-seeded case would handle fresh VM setups before networking might be fully configured (though other auth methods as fallback would be good enough in most cases, I think). I've been thinking about this as breakglass problem. How do you get into your server if your IDP is offline or you lose internet connectivity. My recommendation has been to have a standard public key SSH account breakglass. A pre-seeded JWKS or alternative JWKS would let you have the same policy controls but allow you to create valid keys in extreme circumstances. I really like this. I created an issue to track this. Let me knof you want to do the implementation https://github.com/openpubkey/opkssh/issues/44 https://github.com/openpubkey/opkssh/issues/44

deng 2y ago

What would you say is the advantage of this approach over integrating OIDC into a separate service, like what Ubuntu is trying with authd? (see https://ubuntu.com/blog/authd-oidc-authentication-for-ubuntu-desktop-server https://ubuntu.com/blog/authd-oidc-authentication-for-ubuntu...)

EthanHeilman 2y ago
Thanks for that link, I hadn't heard about this. It looks really cool and I am glad to see ubuntu doing this. I should send ubuntu an email. Sadly I can not offer an opinion as I don't know how authd works. I intend to find.
kbolino 2y ago
Some key differences I observe: OPKSSH covers only logging in through SSH to an existing user account, while authd covers all forms of login (console, graphical, SSH) and user/group management. The latter makes it much more of a full AAA product rather than just a new way to login with SSH. This means it's a deeper investment, with implications for network file systems (as covered in the docs), while OPKSSH can be added on top of just about any existing infrastructure. In terms of process, authd uses the Device Authorization Flow to handle logins, which is more vulnerable to phishing. It also requires both sides to have online access to the IdP, whereas the ID token-based approach of OPKSSH allows the authenticating side to have no (*) or limited outbound connectivity. Also, authd seems to support only Microsoft and Google as IdPs right now, whereas OPKSSH (since it builds on OpenPubkey) supports any OpenID Connect IdP. * = In theory, at least; the current implementation doesn't fully deliver on this, though the one online resource it does need is fairly static and quite cacheable

ale42 2y ago

The idea of using SSO for SSH sounds interesting for some applications, but does the login process really need to be browser-based? Can't we just have the login prompt in the terminal (without needing to run a headless browser behind-the-scenes of course)? I'm often working on headless machines, and other devices that definitely don't have a browser installed, and it would be pretty painful to use (not to mention that when working in a terminal, I find very annoying to have to switch to a browser, or to any other window by the way).

EthanHeilman 2y ago
All the major OpenID Provider want you to use a browser so that users aren't exposing their raw credentials like passwords to an application. We did have an experimental version of this working in a terminal for integration tests a long time ago, but Google views that as malicious behavior and tries to prevent you from doing that. It turns into an arms race with the IdPs. The good news is you only have to login through the browser once in the morning and then you can use the generated ssh key all day long.
- fc417fc802 2y ago
  The browser is also an application. Of course I somehow doubt ELinks will be working with the Google auth page anytime soon. It seems that the goal is to minimize the number of applications into which users view entering their credentials as "normal". The obvious missing piece then is some standardized FOSS project to handle CLI login. Of course that is also unlikely to go over well since what the centralized providers actually want (which is fundamentally incompatible with user freedoms) is attestation. Arbitrarily blessing a few browser implementations that are extremely difficult to compile on your own is just a roundabout method to approximate that (IMO anyway). Edit: It seems like a mistake to me to conflate anit-phishing efforts and IdP. Anti-phishing should be via hardware tokens or TOTP or whatever. IdP should be about large corporations managing user accounts or about individuals gaining convenience, including by serving as an adapter so that the latest popular standard can be used without each downstream service needing to adopt it.
  - 2y ago

apitman 2y ago

1. Can I use my own indiehosted OP? 2. Looks like this streamlines the server trusting the client. Does it do anything for the client trusting the server? I feel gross saying it, but I almost wonder if we should be moving towards some sort of TLS-based protocol for remote login rather than doubling down on SSH, due to the assurances provided by CAs.