(1) Authentication bypass to your email service is already game-over for almost every serious company.
(2) Google (if that's what you're using) has better MFA and access control than what you're going to roll yourself.
(3) Having multiple sources of truth for authentication is a corpsec nightmare, and companies that don't have that invariably wind up accidentally persisting access for departed team members or contractors, and, worse, no single place to consult for a reliable catalog of who has access to what, which is why if you poll CISOs at large-ish tech companies, they'll universally tell you than one of the first 5 things they did when they took over was get SSO stood up.
(4) The "automated key distribution and revocation" system you roll yourself will be jankier and less safe than the certificate-based systems that already exist.
(5) Because that automated key distribution and revocation system does not in fact exist, what you're really saying is that you're going to live with developers having long-lived keys on their laptops.
If you don't trust Google, set up Shibboleth or something; the Google stuff is a sideshow. But the idea that you should manage SSH authentication separately from the rest of your authentication is pretty unserious. I spent about 4 years, recently, parachuting into dozens of mid-sized startups, all of them clueful, and except for the teams that had SSO-linked SSH access, SSH management was invariably a total nightmare. The "just manage SSH directly" approach is, empirically, a failed model.
I'm sure it's different for large megacorps, but if you have less than 100 devs then the single point of failure in your SSO scheme is a far bigger security and operational risk than having long-lived keys on some dev's laptop.
> the rest of your authentication
What is "the rest of your authentication" in this context? Corporate email? As far as I know, SSH is the only real authentication possible here.
