Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Forum Discussion
casmithva
2 years agoNew Contributor
Support for SSH Certificates (2024)
This question came up a couple of times in 2022, but it didn't look like anything was resolved. Since it's been two years...
For those unfamiliar with the concept, SSH certificates are host and us...
john-heaton
7 days agoNew Member
I wanted to add to this a bit, first to share our use case in case it helps, secondly to share a partial workaround, and lastly to add my voice to the people wanting this feature.
We use SSH Certificate Authentication with Vault/OpenBao as the SSH CA. Our users will request certificates for the specific user they need to log in as. The request flow is to send their public key to a signer endpoint that validates they have the appropriate rights to get a signature, and if successful, the certificate is issued and saved onto the requesting user's system. The certificates are short lived, but easy to re-acquire if they are a valid user.
As noted in the original post, SSH CA's make it trivial to manage a large number of SSH users without maintaining `authorized_keys` files on all the servers we operate.
With regard to how we operate and use SSH CAs, We script a lot of this to make it easy, but the generalized flow is:
bao login ...
bao write -field=signed_key ssh/sign/docker public_key=@/Users/foo/.ssh/id_ed25519.pub > /Users/foo/.ssh/id_ed25519-cert.pubNote, I could use `op run` to get the Public Key from 1Password, but did not want to complicate the example more.
I can use this flow with 1Password's `ssh-agent` if I do the following in my `~/.ssh/config`:
Host some-server
Hostname ...
User docker
CertificateFile ~/.ssh/id_ed25519-cert.pub
IdentitiesOnly yesThe `ssh` client will use the 1Password `ssh-agent` for the key, and read the certificate from the file. So I can log in using a certificate.
This breaks down on the remote host if I need to utilize something like `ssh-agent` Forwarding. Since the key was never available in the 1Password `ssh-agent`, it is not available in the forwarded set of credentials.
So, it partially works, but it is an imperfect solution.
Ideally, I would love to see one of the following as a solution to this:
- Some way to note in `~/.config/1Password/ssh/agent.toml` that local certificate files should be forwarded if they match a key already in the agent
- Some way to store the certificate in 1Password. If the "SSH Key" secret type could be extended to also allow attaching a certificate file or the contents, I could change the flow I demonstrated above to use `op` to update the key entry.
Lastly, I would love to push 1Password-based `ssh-agent` out more broadly to my colleagues. It would be great to have another layer of MFA by virtue of using 1Password. But the lack of support for certificates in 1Password make it impossible for us to use this outside testing.
alsofelix
7 days agoNew Contributor
Yeah the ~/.ssh/config solution is what i’m currently using however as you mention it’d be great to have 1 password handle it all