Bitwarden's ssh-agent

 

The most secure way of accessing external ssh servers is the use of ssh-keys and I'm deploying them regularly. The private key is stored on my hard drive, and I'm protecting it with a passphrase. Remembering the passphrase especially for a site you rarely use has always been a PITA.

Since the beginning of this year (2025) the password manager Bitwarden allows you to manage your ssh-keys as well. So I gave it a try.

Under Ubuntu you have to install the Bitwarden desktop app from the snap repo and connect it to your vault. After setting SSH_AUTH_SOCK in your .bashrc the desktop app acts as your ssh-agent:

export SSH_AUTH_SOCK=/home/your_user_name/snap/bitwarden/current/.bitwarden-ssh-agent.sock

While importing keys I've noticed that Bitwarden only likes the "new ones" (that use Ed25519 elliptic curve crypto).  It was a good opportunity to re-key.

Bitwarden itself always generates Ed25519 keys.  The reason might be that this special kind of key allows you to calculate the public key from the private one.

When importing keys into Bitwarden I had to provide the passphrase to my keys, which made me hesitate - perhaps a Gibson-ian reaction :) - because it meant that the key is stored "naked" in the Bitwarden vault.
I would have liked it more if Bitwarden would have provided the passphrase on request - but this would have made integration as ssh-agent impossible.

How is the risk mitigated?

• You are prompted each time a ssh-key is requested from the vault, which is an improvement over the regular ssh-agent.
• There is no indication where a key can be used, if you don't put it into the comment.
• Up until now Bitwarden has a spotless record of securing your vault.

Integration with .ssh/config

The .ssh/config file allows you to configure additional items like hostname, user name, port, the ssh-key AKA the identity file, and port forwarding rules for a given host.  This way you don't have to specify them every time in a ssh command.  If and only if an identity file is configured for a given host a ssh-agent will be queried.

If you generate the ssh-key within Bitwarden the private key is stored in your vault.  But what do you put into the IdentityFile field to make the system query the Bitwarden app?

As Kiko Piris pointed out here, it needn’t be the private key that is stored on the hard drive.  It might also be the public key.  This will not help you if the Bitwarden app is not running, but at least it will make ssh try to contact the ssh-agent.

You might have noticed during the regular use of the Bitwarden app that the IdentityFile field has to be present in the .ssh/config file but the key file itself is not used.
I still have my passphrase-protected private keys on my hard drive with the IdentityFile field pointing to them.  But when I log in with ssh I’m not queried for the passphrase, instead the Bitwarden Desktop app pops up requesting confirmation to use the key it has stored in its vault.

The Bitwarden app has a button that copies the public key into the clipboard which can be used to create the public key file which then can be specified in the IdentityFile field.

It is - as usual - a compromise between security and convenience.  If it fits your risk profile it's a nice tool.