I've seen projects that'll do the SSH CA part, but unless I overlooked it I didn't see any RBAC or mapping ability to restrict users to specific servers.
This is one of a handful of problems we're working to solve / streamline for an SSH product. We might even open source this bit, but not sure yet. If we don't, it still probably wouldn't be $hundreds/$thousands per month unless you have a huge org. If you're interested at all I'd love to talk more about this -- what your requirements are, whether you want hosted/not hosted, whether you want to pay at all / how much you'd be willing to pay, etc. Easiest thing to do to stay in the loop is send us your email at https://smallstep.com/sso-ssh/ by "requesting early access" and we'll reach out to schedule a convo & keep you updated as we make progress. Or just watch our blog! :)
I think I was a bit vague about RBAC. I'm thinking that the user account creation isn't vital in this use case since the audit log holds who generated/access. It's more about controlling who can generate a cert for what.
Eg, I think Teleport's model has the RBAC config at or near the CA part, so the cert generation either happens if authorized or denied if not.
We also have a one-time-token mechanism that you can have some trusted infra like Puppet issue to hosts as they come up. The token includes the specific name that you want bound in the cert. It can only be exchanged for a cert with that subject.
Super secretly: we also have a whole policy language and enforcement engine that we'll eventually get around to doing something with and would address this issue pretty comprehensively.
Edit:
After reading your comment again I think I still might be misunderstanding your use case. Are you talking about having principals like "frontend" and "backend" and then having RBAC that says "mike can get a cert for frontend"?
SSH only does authentication.
Eg, UserA only has been granted access to ServerB, so only show them ServerB as a target and reject all others.