On 2024-02-12 22:15, Chris Rapier wrote: > > > On 2/9/24 2:49 AM, Nico Kadel-Garcia wrote: >> On Thu, Feb 8, 2024 at 1:18 PM Chris Rapier <rapier@xxxxxxx> 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 > > Largely 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 > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev@xxxxxxxxxxx > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev Hi Chris and others, being on the European side of the coin in quite a similar situation was actually the reason to subscribe to this list in the first place. I can only support your analysis that if you want to hook into existing federations your probably have to use some sort of web-technology. In our case this is also done so that users, who typically have to authenticate to their "home" institutions, can validate the authenticity of the login page, for instance by checking the browsers SSL data. Another important requirement for us is that the users, i.e. the client side, do no have to install any "non-standard" software, but can essentially run with "OS-provided" ssh-clients and web-browsers. This since our users typically connect to many HPC centers and have gotten pretty tired of doing something special for each one of them. In the end the not so elegant solution that we came up with is to use a web-based service for users to upload their SSH public keys to us after identifying themselves using the federated login. While the users also have to maintain a list of by them approved origins for login, for us IP-address or DNS name patterns, they don't have to punch in one-time codes for every login, at the expense of some security. Technically for us the biggest challenge was that web-browsers, for good reason, try to isolate a web-site from direct interaction with for instance the file-system of the client-computer. Consequently, we have not yet found a good way to for example get a token, e.g. a SSH key or certificate, in or out of the web-browser into the non-web part, for instance a SSH agent or nice place of the file-system. In the end our service basically asks the user to locate the SSH pubic key file in the web-browsers file-chooser dialog since one could not even make a suggestion of a file-name to the web-browser that the user simply could approve. It would be interesting to hear what your thoughts and progress is on that matter since I am kind of looking to get to a more widely-used solution than our current deployment. On a side-node the Puhuri project (https://puhuri.neic.no/) also provides some infrastructure to handle SSH public keys for the LUMI supercomputer in Finnland. Best Regards Gilbert Netzer PDC/KTH _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
