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. 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
On 2/8/2024 10:10 AM, Chris Rapier 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. > > 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)).SSH Certificates are a useful token exchange currency for AuthN (and basic AuthZ). We can use OIDC to Hashicorp Vault in either non-interactive mode or MFA mode (via some custom scripting) to turn Kerberos/MFA into OIDC into Vault into an SSH certificate. Said SSH certificate can be used directly with SSH, or via a forked pam-ussh module (with the AuthorizedPrincipalsCommand PR) for other services. It's kind of a winding path, but leverages our existing tooling to solve some problems. Fundamentally, both parties in the federation need to decide on which AuthN transitions they're comfortable trusting. SSH certificates allow annotation via naming conventions to denote source AuthN method, which can then be used in AuthorizedPrincipals to determine access. e.g. Allow someuser at TOTP but deny someuser at password. -- Carson
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