I guess I don't see how this is better than using LDAP or AD authentication on each host?
Also, users tend to hate having to always relogin to SSO; maybe that's because the implementations have poor UX, and maybe there's no secure way around it.
Sure, you can use LDAP or AD or any other number of things to control server authentication as well as mapping some global database of user IDs to accounts. You could also do other things like combine this with a 2FA solution like Duo.
One thing SSH certificates certainly have going for them is that they're actually easy to script and integrate with, and "piecewise" migrate to, in my experience, while using a flow you already are pretty familiar with. I personally didn't use any sort of LDAP or AD setup to back my design; you can implement a custom backend for all this pretty easily yourself. There's nothing inherently confusing about the concept of cryptographic certificate authorities or anything, anymore than public key cryptography itself. It's a relatively natural extension of the SSH design you know already, is my point. Again, the man page is worth reading to understand it all a bit better.
> Also, users tend to hate having to always relogin to SSO; maybe that's because the implementations have poor UX, and maybe there's no secure way around it.
Well, I'll be honest, people who tend to use SSH and would be impacted by this stuff tend to hate lots of things and not always for good reasons. Put another way, listening to developers or whatever about what they hate and what's actually good isn't something I would factor into something like this. SSO is mandatory for very good reasons at any reasonable scale (and by "reasonable" my opinion is you should have it in place at, like, 10+ people.)
Anyway, besides that. There's nothing in theory that prevents you from doing something specific like having the backend refresh the SSO token issued for your SSH certificates every time you log into some server, upto some given interval e.g. logging in at least once a day seems reasonable, but if you login every 5 minutes to a new set of hosts you can refresh the token.
In my case the flow was something like 'my-ssh-ca-wrapper ssh user@bar', which would ask you for a token. I would then get this token by visiting a little webpage I wrote, but in theory it could also just launch the browser itself with xdg-open with a direct link. I just use a password manager to fill out those "SSO" credentials. It isn't ideal or fully integrated but in practice it would only take a few seconds and it's similar enough to corporate SSO setups. But yes, polish is everything for those final few steps. The actual backbone is pretty straightforward, though.
Also, users tend to hate having to always relogin to SSO; maybe that's because the implementations have poor UX, and maybe there's no secure way around it.