The desktop bitwarden can now act as an ssh-agent.
This request is for a similar capability for the command-line bitwarden.
The name of the command-line bitwarden exectuable is bw.
It seems like this could be an option for bw login --agent or as a separate bw agent (and bw agent --off) command that would work only if there were an active login.
I think this behavior should be separate from the bw lock.
Note: I slightly changed the title. (before, it was āAllow the Command-Line Bitwarden (bw) to act as an SSH Agentā)
This is related to an older request.
Most of the earlier request has been implemented.
I want to make sure the CLI version is not forgotten.
As a workaround until the feature is available, Iāve managed to use the following to directly add a key to the OpenSSH agent.
bw get item <ssh-item-id> | jq -r '.sshKey.privateKey' | ssh-add -
Proper support in the bw CLI would be much better, of course. Even adding SSH key support to bw get (to avoid the jq call) would be an improvement: add a new object type for SSH private keys, or maybe repurpose the password object for type 5 items.
I would love to have this feature for my headless system.
Iām also wondering if external contribution is welcome for this feature.
@ChihweiLHBird Guidance for how to propose a code contribution is available here:
Looks nice! Please make it!
+1 for this enhancement!
I created an account just to vote for this but have no reputation, so +1.
Currently, the SSH Agent functionality (key storage, unlock, and signing) is only available through the Bitwarden Desktop application via the native Rust module (desktop_core::ssh_agent). This means users must have the desktop app running to use SSH keys stored in their Bitwarden vault.
Iād like to request SSH Agent support directly in the Bitwarden CLI (bw), allowing the CLI to act as a fully functional SSH agent ā independently from the desktop app.
A new CLI command (e.g., bw ssh-agent) that:
Starts a background process exposing an SSH agent socket (SSH_AUTH_SOCK)
Reads SSH keys from the unlocked vault
Responds to standard SSH agent protocol requests (identity listing, signing)
Supports the existing key approval settings (āAsk for authorization when using SSH agentā)
The existing Rust implementation in desktop_core could potentially be shared or extracted into a common library to avoid code duplication between desktop and CLI.
Headless servers / remote environments where installing a desktop GUI app is not practical
WSL / containers / VMs where the desktop appās SSH agent socket is not accessible or reliable
CI/CD pipelines needing SSH key access from the vault without a GUI dependency
Terminal-first workflows ā many developers prefer not to depend on a GUI app just to unlock SSH keys
Linux servers where only the CLI can realistically be installed
Using the desktop app ā not viable on headless or server environments
Exporting SSH keys manually ā defeats the purpose of centralized key management in Bitwarden
Using bw get to extract private keys into files ā insecure, no SSH agent protocol support, keys end up on disk in plaintext
@thomas.s Welcome to the forum!
I moved your request into an existing feature request on the same topic.
My suggestion (and this includes the Desktop client as well) is to just have the ability for Bitwarden to add keys to an existing agent.
Currently the desktop agent doesnāt allow you to add keys to the agent that are not stored in Bitwarden, and you likely lose a lot of features by reimplementing a full SSH agent rather than just having the ability Bitwarden add keys to an existing agent (like ssh-agent or Pageant).
Windows, Mac, and Linux all ship with ssh-agent nowadays (and Pageant is an easy download/install) so Iām not sure of the benefit of a full ssh agent implementation (especially one as broken as Bitwarden desktop)
Yes, @ggiesen being able to use a regular ssh agent could be a better alternative. Iām struggling with trying to get agent forwarding working.
So far, I can only forward the agent by using ssh -A server from powershell. I can then successfully list ssh keys on the remote server with ssh-add -l, but I have not been able to actually log in via the agentās keys yet.