-
-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fallback to forwarding to another ssh-agent for unsupported or unknown keys #19
Comments
I've considered this feature a few times, but it seems like configuring the agent on a per-host basis would work for those use cases. https://github.com/FiloSottile/yubikey-agent#coexisting-with-other-ssh-agents Does this work for you? |
I've seen this part of the README but I was wondering if you ever wanted to do this. |
It depends on whether it's necessary to handle use cases not covered by the IdentityAgent solution. Can you help me understand if and why IdentityAgent wouldn't work for you? |
Perhaps agent forwarding is the use case? I want to run yubikey-agent on my laptop, then ssh to a server with agent forwarded. and check out my git repo on the server, while my private key is still in the Yubikey. But I also have other ssh keys. |
That does sound like a use case for forwarding, yes. Now the question is if it's common enough to justify the complexity. I am not convinced but will leave this open to collect feedback. |
My use case for this feature + most of my colleagues: Maybe it es easier to just forward failing requests and "ssh-add-requests" to another ssh-agent listening on a different socket. |
Related GnuPG |
Is it possible to add other types of SSH keys to the agent as well? Currently, I can't add RSA or ed25519 keys.
The text was updated successfully, but these errors were encountered: