On Thu, Feb 8, 2024 at 1:18?PM Chris Rapier <rapier at psc.edu> wrote:> > I know that there are some methods to use federated identities (e.g. > OAuth2) with SSH authentication but, from what I've seen, they largely > seem clunky and require users to interact with web browsers to get one > time tokens. Which is sort of acceptable for occasional logins but > doesn't work with automated/scripted actions.Is there some reason you wouldn't simply use Kerberos, baked into Samba and Active Directory, with the long established token handling provided by Kerberos? Convincing Kerbers and the AD admin who may not realize they have it to permit that underlying authentication technology, but it's been stable for decades Part of the difficulty seems to be every bureaucracy's desire to have their own special rules and not talk to each other without a lot of Gant charts and big picture diagrams, but I've been taking advantage of the underlying Kerberos behind the backs of AD admin for decades. Unfortunately, everyone seems to want to have their own "invented here" form of authentication token handling, rather than sticking with basics. My old classmates at MIT worked *very hard* to make that work, and to resist abuse, and it still works quite well.> I'm just wondering if anyone has done any work on this or has thoughts > on it. I know it would be useful in some contexts (in my case, cross > realm access of independent yet federated services that are pretty > common in R&E HPC communities (e.g. ACCESS)). > > Chris > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Practically speaking, most popular IAM and SSO solutions offer OIDC SAML tokens but do not offer Kerberos tickets.? OpenID Connect is a standard which itself is based on RFC6749 (OAuth2). This provides a compelling reason to support it in addition to Kerberos.? I'll also note that OIDC tokens are easy to validate without a bidirectional trust relationship between the IdP and RP. SSH authentication via OAuth2, in particular, would save complexity at most organizations I've worked with.? All of them so far have preferred things like automated SSH certificate signers or APIs that cause orchestration to add SSH keys to authorized_keys on hosts, before they implement Kerberos just for this. On top of that, Active Directory is a legacy solution now.? Its successor uses OAuth2. On 2024-02-08 23:49, Nico Kadel-Garcia wrote:> On Thu, Feb 8, 2024 at 1:18?PM Chris Rapier <rapier at psc.edu> wrote: >> I know that there are some methods to use federated identities (e.g. >> OAuth2) with SSH authentication but, from what I've seen, they largely >> seem clunky and require users to interact with web browsers to get one >> time tokens. Which is sort of acceptable for occasional logins but >> doesn't work with automated/scripted actions. > Is there some reason you wouldn't simply use Kerberos, baked into > Samba and Active Directory, with the long established token handling > provided by Kerberos? Convincing Kerbers and the AD admin who may not > realize they have it to permit that underlying authentication > technology, but it's been stable for decades Part of the difficulty > seems to be every bureaucracy's desire to have their own special rules > and not talk to each other without a lot of Gant charts and big > picture diagrams, but I've been taking advantage of the underlying > Kerberos behind the backs of AD admin for decades. > > Unfortunately, everyone seems to want to have their own "invented > here" form of authentication token handling, rather than sticking with > basics. My old classmates at MIT worked *very hard* to make that work, > and to resist abuse, and it still works quite well. > > >> I'm just wondering if anyone has done any work on this or has thoughts >> on it. I know it would be useful in some contexts (in my case, cross >> realm access of independent yet federated services that are pretty >> common in R&E HPC communities (e.g. ACCESS)). >> >> Chris >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
On 2/9/24 2:49 AM, Nico Kadel-Garcia wrote:> On Thu, Feb 8, 2024 at 1:18?PM Chris Rapier <rapier at psc.edu> wrote: >> >> I know that there are some methods to use federated identities (e.g. >> OAuth2) with SSH authentication but, from what I've seen, they largely >> seem clunky and require users to interact with web browsers to get one >> time tokens. Which is sort of acceptable for occasional logins but >> doesn't work with automated/scripted actions. > > Is there some reason you wouldn't simply use Kerberos, baked into > Samba and Active Directory, with the long established token handling > provided by Kerberos? Convincing Kerbers and the AD admin who may notLargely because I'm trying to work within an existing system that has established methodologies. The really fun part is that I'd be trying to do this in a way that supports European R&E communities and US R&E communities which use different methodologies and have different organizational structures. Prior experience with kerberos in these communities has not proven to be fruitful. It may be worth trying to revisit that, but I don't have any pull in transnational EU R&E HPN consortiums. They're pretty taken with OAuth which is great if you are doing everything in a browser. The US consortium I have more connections with but again, they're pretty taken with web based SSOs on their science gateways. Chris