Today I implemented SSO for SSH using Vault and Authentik.
In this post, I’ll explain the basic idea behind the setup, why it’s useful, and some of the trade-offs I encountered.
The Problem with Traditional SSH Keys
The Problem with Traditional SSH Keys
Traditional SSH keys are static and often rarely changed, which creates a significant security risk. In practice, keys are almost never rotated and they do not expire.
Additionally, there is usually no built-in auditability, making it difficult to track who has access to which systems.
The Solution
SSO for SSH addresses these issues by using short-lived signed SSH certificates.
Instead of static keys, your SSH key is signed with a short TTL (in my case, 2 hours).
Even if the key is compromised, it becomes useless after a short time window.
Other huge benefit is that the setup is just way more frictionless at the start of the day you sign in once to your single sign-on provider and your logged in for the day.
Another major benefit is improved usability. You authenticate once with your SSO provider and gain access for the duration of the session.
This reduces friction significantly, but it also makes it critical to properly secure your SSO (e.g., strong authentication and high availability).
What You Need
In my homelab, I already had Authentik running as my SSO provider. You can use any OIDC-compatible provider, but for personal use I can highly recommend Authentik.
For SSH certificate signing, I used Vault by Hashicorp.
Setup Overview
After deploying Vault on a new VM and hardening it, I configured OIDC authentication via Authentik. This allowed me to authenticate to Vault using my SSO identity.
Next, I enabled the SSH secrets engine in Vault, which handles certificate signing.
Finally, I distributed Vault’s SSH CA public key to all my VMs and included it in my VM templates for future instances.
To streamline authentication, I created a small script integrated into my shell that automatically handles logging into Vault, so I don’t have to run the command manually each time.
Vault signs your SSH key with a 2-hour TTL. You authenticate to Vault via Authentik it opens a browser window and if you're already logged in, it signs you in automatically. With your signed key you can SSH into any VM for that 2-hour window, after which you re-authenticate.
User
↓
Authentik (SSO)
↓
Vault (signs SSH cert)
↓
SSH Server (trusts CA)
On the server side, SSH is configured to trust Vault’s CA by adding its public key to the TrustedUserCAKeys setting.
Trade-offs and challenges
Single Point of Failure:
If Vault or Authentik is unavailable, SSH access may break entirely depending on the setup. This shifts risk from key compromise to availability.
Integration:
This setup does not work out-of-the-box with tools that rely on traditional SSH keys, such some mobile SSH clients.
This is not just an more frictionless setup but also more secure than just using ssh key since even if the my signed ssh key gets compromised it can only be used inside that 2 hour window unlike traditonal static ssh key.
Hope this inspired you to replace your static ssh keys and rethink how you manage SSH access : )