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.