Feedback to ssh-agent from day-to-day use

I’ll update this post as time goes on, and I find more things are suboptimal.

I’ve been waiting quite a long time for Bitwarden to enable the ssh-agent, and now that I can use it, I find that there are a few points that cause me friction, working with it on a day-to-day basis.

I’m on Linux (NixOS), and I use ssh keys for all things git related, so on a busy day, literally hundreds of times. Here are the points that aren’t that great so far:

Re-minimize (/ close) Bitwarden

If Bitwarden was minimized, either to the drawer or to the tray, it should return to that state, and thus re-focus the app I was previously working in.

Quicker authorization

I would prefer it, if the “Authorize” button would have initial focus, instead of the “X” for closing the popup inside Bitwarden. Currently, I have to hit Tab + Enter, instead of just enter, which is a bit inconvenient.
If this is not desirable, due to the possibility of accidental confirmations, maybe add alt + a (authorize) / d (deny) shortcuts to such prompts?

Cache the authorization of keys

Git clients often make multiple requests to generate their result(s). So I often have to approve 3 or more prompts, just so I can start committing.
Even without a git client, I make multiple requests, when committing. At least one git pull, followed by the eventual git commit (this obviously doesn’t normally make a request) and git push

I would find it useful when the key stays available for some time, e.g.: 5 minutes.

Furthermore, it would be worth considering allowing unrestricted access to the SSH-key, once it has been authorized. Many git clients can be configured (or are set up by default), to do periodic fetches, to inform the user about potential updates on the remote.

2 Likes

Great issues. Those are my problems and also that the authorise box is not modal. If you click outside of the box you lose the option to authorise and need the client to force a re-prompt

Integrating the actions more with the desktop environment

I feel like, this is probably a dream that can’t come true, but it would be so awesome if there was a way to more tightly integrate actions with the desktop environment. Here’s my story:

I’m using tons of workspaces and with a tiling window system (I’m using COSMIC). Whenever I type git push into my terminal (or the IDE decides to perform a git fetch [which I recommend disabling for now]), all my window move about like I’ve just inserted a new image into the middle of a Word document, and I get a new window in the middle of it: Bitwarden. Like @gooseleggs stated, in that window is a popup. Which can be accidentally exited out of, requiring me to restart the whole ordeal. Or, what if, I have Bitwarden open on another workspace? Either the desktop environment switches my workspace, or, like COSMIC, they highlight the workspace, indicating that an app needs action. Several times, this has led to me waiting for something to happen, only to realize I needed to approve the usage of the key on another workspace.

But imagine this! I perform an action that requires me to authenticate, and magically, a desktop environment native popup appears:


Because it’s a native dialog, the desktop environment knows to position it on top of all my applications, even though I’m using a tiling window system.


Sadly, I’m not a Linux app developer, so I’m not sure how to go about that. My first idea was to look for a portal. And there is a (as far as I’m concerned) private API, I didn’t find a public counterpart for it.

This was, by the way, also, how I produced the dialog in the screenshot:

gdbus call --session --dest org.freedesktop.impl.portal.desktop.cosmic --object-path /org/freedesktop/portal/desktop --method org.freedesktop.impl.portal.Access.AccessDialog   "/org/freedesktop/portal/desktop/request/1"   ""   ""   "Permission Request"   "SSH-key access was requested"   "Allow access?"   "{}"

This call requires gdlib and --dest would need to be substituted with the users’ portal implementation. For example, here is the dialog with the GTK implementation (org.freedesktop.impl.portal.desktop.gtk) of the portal:

Maybe someone with more knowledge could give insight, but more system based interactions like this, would be absolutely premium!