This is what Bitwarden needs to do.
In the meantime, I’m just increasing MaxAuthTries to 20:
MaxAuthTries 20
I would like to see a toggle for adding keys to the agent, or not.
I like to add all my SSH keys to Bitwarden, but I do not use all of them very often. A lot of my SSH keys are used for services, so they do not need to be added to the SSH agent generally.
1 Like
Thanks to @borsarinicola, @schuhu, @Schale01 for the bash script work and @tslivede for the pwsh equivalent.
Seconded.
I only recently figured out how and started using the Bitwarden ssh-agent myself. As I am apt to do–I immediately went FULL overboard and started creating a unique ssh key for every host I have access to. With the keys being stored in an encrypted vault that syncs across (client) devices–it seemed to make sense to treat these keys more like creating a unique password for every service you use. My main machine has the relevant .ssh/config host entries with corresponding IdentiyFile bw-{host}.pub records. Each host has the relevant entry in authorized_keys for its dedicated Bitwarden stored credential and a hardware security key alternate.
Does my hobby homelab need this level of security? Absolutely not! 
The main drawback to this approach that gives me pause is the need to have those bw-{host}.pub keys on any device that I connect from.
It would be great if Bitwarden and the ssh-agent could in some way:
- NOT divulge the names of every single SSH key saved in my vault, to every host which I initiate a connection to.
- Accomplish #1, without the need to also expose those public keys (with identifying names) to even the host from which I am connecting.
Of course, I could just use a single “master” SSH key for all my various projects but given that authorizing 1 of (256) SSH keys with Bitwarden’s ssh-agent works the same as authorizing 1 of 1, I’d prefer the more secure approach.
I made a proof of concept implementation of a “use with ssh agent” toggle box. Feel free to try it out
2 Likes
I wrote a CLI to automatically configure SSH public keys in .ssh/config (IdentityFile and IdentitiesOnly) based on Bitwarden’s custom fields and Bitwarden CLI.
It kinda works around this issue without doing the whole SSH configuration by yourself.
It may be a temporary solution but at least it works for now…
1 Like
I’d like to add the perspective of MobaXterm (MoTTY) users on Windows. MoTTY is based on PuTTY, and unlike OpenSSH it does not support ~/.ssh/config or options like IdentitiesOnly. It automatically tries all keys exposed by the agent.
It’s worth noting that MobaXterm’s local terminal can use the native OpenSSH client (and therefore respects ~/.ssh/config), but saved SSH sessions (“bookmarks”) rely on MoTTY. In those cases, there is no built-in way to restrict which keys are offered by the agent.
With the Bitwarden SSH agent, this means every key in the vault is exposed, which can quickly lead to “Too many authentication failures” on servers that limit authentication attempts.
In this context, having the ability to control which keys are exposed by the agent (per key or per host) would significantly improve the experience for Windows/MobaXterm users.
1 Like
How it gets implemented technically is beyond me but it makes a LOT of sense to me for Bitwarden to have some way to restrict which keys are presented to which hosts, in a way very similar to the domain matching for password auto-fill. Glad to see work being done on this, officially and via the community.
The main limitation is that SSH agents don’t receive any domain or hostname information when they are queried. The client simply asks the agent for all available identities (REQUEST_IDENTITIES), and the agent returns every loaded key. There is no context about which host is being contacted, so domain-style matching (like password autofill) isn’t technically possible at the agent level.
Because of that, the practical solution would be to let users control which keys are loaded/exposed in the agent in the first place, rather than trying to match keys dynamically to a host.
1 Like
are you saying ssh is a stupid protocol? /s
1 Like
That would be a definite improvement. If this setting could be set and specific to the particular Bitwarden Desktop client install and not just to the individual vault items, that would solve it. I know there are some settings which sync to the account and remain the same across instances but there are many that only scope to the particular extension or desktop client install.
Work PC gets access to SSH keys for work related hosts. Personal Mac laptop gets my Homelab SSH keys. I realize there’s a balance to strike between keeping this feature simple and easy to use versus Microsoft 365 levels of configuration purgatory…