The recently enabled/release SSH agent works well for most servers I need to authenticate to (thanks for your work in putting this in!), however an issue I had with some hosted servers (so I have no admin control) is that they limit the number of authentication requests. In this case the server quickly terminates the connection as Bitwarden offers every SSH key in the vault (admittedly I probably have too many, but requirements make it difficult to reduce this number).
It would be useful if Bitwarden provided a way to specify which key is used/offered so that the server doesn’t block connections.
Possible options (without much understanding of how the ssh-agent interacts with the server)
Allow use of the -i ssh flag to specify the name of a key to use and only offer this key when the flag is present
Add a new field in the SSH key item that stores the user@hostname combinations and only offers those keys to those hosts
Allow specifying a preference order to offer keys
When Bitwarden receives a request, rather than Authorize/Deny have a popup to select the key (similar to passkeys)
I have found as a workaround it is possible to keep the private keys in my .ssh folder for these servers, however this creates a double authentication: specify key to use → approve in Bitwarden → enter key password;
and it would be more convenient to keep everything in Bitwarden than splitting between two storage locations/methods.
I would really like to see all of them being implemented in bitwarden. Without all of them it’s not really very usable as a daily driver.
To add some information: by default, most openssh servers support having a maximum of 6 keys offered by the client. There is a parameter in the server to change this: MaxAuthTries
And specifying a couple of options on the openssh client you can limit which keys are offered to the server:
Agree. People will hit this limit quickly. I would like some options for the keys as well like favourite to always make available or ability to toggle availability or a pop up list. Great start for this ability. Hopefully updates for this roll quickly.
Can’t you just store public keys instead? Wouldn’t that make SSH Agent select the correct private key automatically
That is what KeepassXC suggests in for the same issue:
If you prefer storing your private key inside your database using an attachment, you can still do so. Instead of letting the IdentityFile directive point to a private key file, let it point to your public key file. The SSH Agent will use the provided information to select the correct private key.
I recently began testing the ssh-agent feature and find it is a great improvement over other agents like Pageant. Having one master password to unlock all keys is quite nice.
I signed up to this forum today ready to file a feature request for much of the same points already mentioned in this thread. I think the Bitwarden ssh-agent needs better restriction for which keys are offered under different circumstances. Personally, I have one vault with multiple SSH keys to various different servers sorted into folders by their site/location. The different sites are not related to each other, so I do not want my SSH client attempting to authenticate with keys for another site. By design, each time the SSH client (PuTTY in my case) attempts to authenticate to a server with a key, the server has to check if that key is allowed (usually by looking in the authorized_keys file) and reply if authentication using the key is allowed or not. For security reasons, only so many keys can be checked before the connection will be closed by the server. This is standard on many OpenSSH server configurations.
For my use case, I would like the ability to restrict which keys are offered by the ssh-agent based on some sort of matching criteria. Here are a couple ways I think this can be accomplished:
Each Bitwarden client can keep its own client-side settings for which individual keys / folders / collections should be available to the ssh-agent running on that host
Bitwarden should support SSH agent restriction, introduced in OpenSSH 8.9. This will restrict keys based on an allowed list of usernames and/or destination hosts.
I have been working around this by doing as the others have, specifying the public key file as the identity to be used. OpenSSH client supports this with the -i flag or IdentityFile configuration option. PuTTY similarly lets you use the public key file in place of the usual .ppk private key under Connection → SSH → Auth → Credentials. However, this is not a perfect solution and I have problems when connecting to arbitrary servers where I do not know which SSH keys are authorized.
What about if the ssh client does not support agent restriction we get a selection box? This box would contain a search bar and a filter (as Bitwarden seems to want to not recognise folders) to select a folder which is persistent across requests. Then you can select which key to use.
If the client can pass through an identifier that Bitwarden can use then it just prompts for authorisation of that key.
Hello,
I raised an issue/feature request and redirected here. https://github.com/bitwarden/clients/issues/13401
I can’t even vote, I struggle to understand the process. Double ticket queue + community vote…
Seems Bitwarden think people use 5 keys max.
So it won’t be my ssh-key manager for now.
Yah I was so excited about Bitwarden SSH Agent until I hit this. I basically can’t use it now. Seems ridiculous such a simple thing would be the end of something amazing. Surely there has to be a way to add some ‘host’ field to our SSH keys and have the Bitwarden Agent only respond with keys matching said host.
The best way, would be to be able to provide the key name in the IdentityFile attribute of the ~/.ssh/config file, without having to have the file locally on the host.
To be clear, this is a configured limit on the server that is being authenticated to, the ssh-agent itself does not have a limit of keys it offers.
Surely there has to be a way to add some ‘host’ field to our SSH keys and have the Bitwarden Agent only respond with keys matching said host.
It is sadly not as easy. The agent protocol spec does not give a way for the client to see which host (or even hostkey) is being authenticated to, only which session-id is being signed. There are some openssh specific (but not on other ssh servers) extensions such as [email protected], which do prove the hostkey, which could be combined with the known_host file to get the hostname, for those sessions.
I think you can set the IdentityFile to the pubkey copied from Bitwarden, saved to disk, to force it to use the corresponding private key for auth:
Identity File
Specifies a file from which the user’s […] authentication identity is read. You can also specify a public key file to use the corresponding private key that is loaded in ssh-agent(1) when the private key file is not present locally.
I’ve been doing as recommended above (editing the config file with) but I had to bash script to export every pubic key available in the Bitwarden agent. A bit to cumbersome than I was hoping to be honest. Let’s hope this get looked into quickly.
#!/bin/bash
# Output directory (default to ~/.ssh)
OUTPUT_DIR="${1:-$HOME/.ssh}"
# Make sure the directory exists
mkdir -p "$OUTPUT_DIR"
# Loop over each key in the agent
ssh-add -L | while read -r key type comment; do
# Sanitize the comment to be safe as a filename
safe_name=$(echo "$comment" | sed 's/[\/: ]/_/g')
filename="${OUTPUT_DIR}/${safe_name}.pub"
# Write the key to file
echo "$key $type $comment" > "$filename"
chmod 600 "$filename"
echo "✅ Saved: $filename"
done
echo "🎉 Done saving all agent keys!"
