I feel like for SSH certs to expand beyond large companies, there's the need for an open-source service which does the issuing of short-lived certs after a user authenticates. I know smallstep, but their offer feels open-core/freemium.
Infisical SSH is actually an extension of the Infisical platform which is open source and used by a ton of companies for secrets management.
- does you organization use ssh certs?
- how big is the org? ("I know most IT", or "it's impossible to know the whole IT"?)
- were you the ones that proposed and implemented that change? :)
SSH certs make so much sense and I know about them for a long time. Yet never implemented that approach - we had at most 2 people that were actually interested. And now for me everything is http API's and oauth, so I don't need it any more. I wonder what are reasons orgs don't use ssh certs by default.
Everywhere else I worked just used ssh keys, either deployed via ansible or via LDAP because it's so much more simple unless there's a high need for an audit trail with proof of approval. SSH keys scale perfectly fine otherwise.
Unless I'm desperate, I'll never work for a managed services company again, so hopefully I'll never need to bother.
I'd say SSH certificate-based authentication is implemented widely at big tech and larger enterprises (tons of sources on it) but hasn't received the same mainstream adoption as SSH public key authentication because the administrative experience to set it up can be quite cumbersome despite how much benefit it provides. Put differently, there's always been a tradeoff in terms of configuration effort and benefits reaped.
With Infisical SSH, we've tried to abstract away as much complexity as possible and give folks the ability to implement a SSH certificate-based access scheme across infrastructure with minimal administrative overhead.
But since apparently ssh is now obsolete (as I was told here a week ago or so) maybe it makes no difference.
Like NFS.
Oh, wait.
I am on a corporate desktop where the agent service is not running:
C:\>ssh-agent
unable to start ssh-agent service, error :1058
https://the.earth.li/~sgtatham/putty/0.80/htmldoc/Chapter9.h...
I do see that pageant.exe supports certificates, but the discussion is quite brief.
We used to use a method that was identical to this using Vault. Even wrote our own mini-CLI with a similar usage pattern. However, nowadays, we rely on Tailscale SSH (with a break-glass key) and have never really felt the need for an alternative.
You're right in noticing that we're moving beyond secrets management into adjacent related verticals as well, specifically branching out more into the larger identity and access management space; secrets management continues to be the bread and butter of Infisical but the way we see it, it would be super nice in the long run to have one unified control plane over all related aspects spanning secrets management to certificate management, SSH access, and more.
One of the core product philosophies of Infisical has always been to abstract away complexity as much as possible while still giving users the ability to customize the tool.
Whereas Vault might, for example, have you explicitly create SSH certificate authorities and require 12+ steps to configure a working SSH certificate-based authentication model, Infisical SSH makes it so you only have to care about users and hosts that is who has access to what with something like 4 steps and if you want more power out of Infisical then that is always possible to build atop.
Good to know regarding Tailscale SSH!
This feels like replacing ssh for shh-with-tracking. Am i missing something ?
Hosts answering to connections using that cert don't have to send anything back to CA. They just need rules "I trust this CA. If a user has a cert from it, and this precise combination of fields match, I consider this user's response trustworthy".
therefore ssh keys do in fact scale.
Ok compare that to this solution: you still have to define sets of users or certificates. You still have to go edit the configuration on every server to put the correct list of certificates on there, so you are managing the lists just the same. If you find out something needs to be revoked you have to go do that.
What's good: You don't have to go touch the servers in a loop except when changing the ACL setup for the servers. You can avoid having anything that can access the key setup for those servers (not really, you are just pretending this is true, but kindof).
What's bad: You have to buy into their model. You have to go change how you do auth on all the servers. Users can't generate their own keys anymore, which is annoying. Some things that magically work with keys will be hard or impossible to configure with certificates, especially home grown stuff. Whenever inifiwhatever gets hacked you are in serious trouble.