I don't understand the obsession in integrating everything with OID services, like Google. People already complain all the time about Google watch-dogging them and then integrate every single service imaginable with their Google account. Shit is just weird to me.
this post was submitted on 28 Mar 2025
75 points (95.2% liked)
Technology
68349 readers
3995 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
I think the Google as an identity provider example is misleading. The more common use case will be medium to small companies where several admins/developers need to login to various servers and where manually adding and revoking keys across these servers will be cumbersome.
As the other commenter said, in those cases, the organization would also deploy its own IDP.
You can run your own IdP on your network
Orgs commonly need idp, fuck managing ssh key auth for hundreds of engineers.
This isn't aimed at individuals or self-hosters, though you can if you find it interesting enough.
fuck managing ssh key auth for hundreds of engineers.
You can pull the ssh key out of LDAP/AD. We did this 10 years ago. Really slick.
Now with modern config management (sit down, Ansible, you millennial junk) the keys update anyway in about a second.
I think the point here is moving away from long-lived ssh keys and using whatever IdP you have (enterprise cloud or local oidc) to provide short-term ssh keys. It generally improves the security posture as it's similar to ssh with certs but less painful to set up.
So does requiring all users to phone you ahead of time to get a temporary password that's only alive for 20 minutes.... But that's also not done because it's...stupid.
There are dozens of tools and methods (like jumpboxes) which facilitate the authorization and usage of currently available and time tested tools for usage with environments without reinventing the wheel. Stepping away from the unix philosophy is heresy of the highest degree.
It's not a problem with the tool, only the plumber.
Stepping away from the unix philosophy
SSH already allows auth with username and password against a local file. This just moves the file.
Mine's having the lazy arse syndrome of using it to sign in to Tailscale and having other friends/family using their SSO from the Big G to simplify them signing into my Tailnet.
Guilty as charged?
Definitely looks like a nice improvement. Functions very like cloud provider CLI SSO, but with a generic tool.
I think for an enterprise use case, supporting the use of the groups claim (or other configurable scopes) is table stakes. Although in those situations, I've also had to use other tools like teleport that come with other enterprise niceties like full session audit capture and playback.
And while everyone should do their own threat and risk modeling, you've now made your ssh connection dependent on an external service that likely needs to reach out over the internet.