Using an SSH Certificate Authority is also my recommendation, but be aware that it's relatively new, so associated tooling with it is not super mature yet. In particular, the user still needs some bits in order to login, and whether they generate it themselves and send it off to get signed, or the bits are generated for them on the backend and the user simply needs to receive them, there's a management aspect to it that isn't a totally solved problem with open source tools.

It's not a difficult problem, mind you, but there was custom code written that runs on developer laptops (OS X and Ubuntu) to support this workflow.

(Despite being a very similar looking string of bytes as more traditional pub/private keys, it's different in the SSH-Agent protocol, so don't assume all ssh-agent-looking daemons support it.)

ScaleFT uses a certificate based approach and issues short lived certain for SSH and RDP. Also has a policy engine to set additional access controls.

I tried to deploy them to grant developers limited time access to the hosts running their services. Didn't really work out and I killed the project.

One other handy feature that we're using is the ability for Vault to set user IDs in the signed key ID field which then get logged by sshd on the remote host. That way we can still audit who exactly logged in if using a single user on the remote host.

Agreed on an SSH Certificate Authority being a good solution. Another open source project (disclaimer: I'm affiliated with it) which provides approval controls is available here: https://github.com/cloudtools/ssh-cert-authority

As a follow up - I would now also take a _very_ serious look at Teleport [1] for managing SSH.

[1]: https://gravitational.com/teleport/

You have to build a new ssh CA for each class of server. There's no mechanism for granting access by host name. This becomes unmanageable fast.

You can represent that pretty easily with principals. Just make sure that each host has itself listed as a principal and generate keys that contain that same string. It's pretty common to have a set of increasingly general principals (I.e. Hostname, cluster, tier, root@everywhere).