Hello,
All app are up to date.
I’ve encountered an annoying thing by activating the SSH-Agent in my zshrc config file with :
export SSH_AUTH_SOCK=/Users/milesteg/Library/Containers/com.bitwarden.desktop/Data/.bitwarden-ssh-agent.sock
I already have in my ~/.ssh/config all my keys referenced, which are in the same folder.ssh xxx command, there is no confirmation whatsoever required with Bitwarden app, but when I use a script that launch a ssh command, I reveive a popup in bitwarden demanding a confirmation to access the ssh-key stored in my Bitwarden Vault:
Everytime my script launch a ssh command I get this message.
Is it possible to have my script granted access without confirmation ? (of course only when Bitwarden is open and my Vault unlocked).
Thanks for the help.
1 Like
I’m having the same issue. I have several applications that use ssh with git commands to fetch and pull updates from github. every time it does this I’m forced to click approve which is very
Update: I just saw this PR on github that solves this issue. waiting for it to be added to the next release
main ← km/ssh-authorize-remember
opened 01:12AM - 26 Mar 25 UTC
## 🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-15871
## 📔 Objective
…
The current behavior of the SSH agent is somewhat annoying in that it requires SSH authorization for every request. When using e.g. VS code, the autopull behavor will prompt frequently. When using e.g. ansible, authorizing to servers is unusable.
Specifically, we have the following scenarios:
```
1. I use 1 key for 1 host only
2. I use 1 key for N sites
3. I sign (a commit/file) with key
4. I use key via forwarding (sign/authorize)
```
4. should always ask. Using keys via forwarding exposes signing access to other hosts, and thus should not be remembered. Signing commits is usually infrequent, but sometimes many signatures rapidly follow (rebase).
1 and 2 can be cached by accessing application, or by host, or both. Since the data for applications or hosts is not properly exposed to Bitwarden desktop yet, (and for applications cannot in all cases because of sandboxing), the simplest approach to make the UX usable until more fine grained permissions are implemented is adding an optional toggle to remember authorizations for 1 key, session wide, until lock.
This PR adds a "SSH prompt behavior" setting with 3 options:
- Always ask
- Never ask
- Remember until lock
In all cases, forwarding will always prompt *even if "never" is selected*.
For remember until lock, this will currently:
- If authorizing an SSH login:
- Remember per key, until lock
- Session wide (all applications) // Can lock down in the future
- For all host destinations (not filtered by hostkey / host) // Can lock down in the future
This can be later locked down to per-host / per-app.
## 📸 Screenshots
[Screencast_20250328_205609.webm](https://github.com/user-attachments/assets/47c94bde-d10f-4ce7-a073-bf16468a09c3)
## ⏰ Reminders before review
- Contributor guidelines followed
- All formatters and local linters executed and passed
- Written new unit and / or integration tests where applicable
- Protected functional changes with optionality (feature flags)
- Used internationalization (i18n) for all UI strings
- CI builds passed
- Communicated to DevOps any deployment requirements
- Updated any necessary documentation (Confluence, contributing docs) or informed the documentation team
## 🦮 Reviewer guidelines
- 👍 (`:+1:`) or similar for great changes
- 📝 (`:memo:`) or ℹ️ (`:information_source:`) for notes or general info
- ❓ (`:question:`) for questions
- 🤔 (`:thinking:`) or 💭 (`:thought_balloon:`) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion
- 🎨 (`:art:`) for suggestions / improvements
- ❌ (`:x:`) or ⚠️ (`:warning:`) for more significant problems or concerns needing attention
- 🌱 (`:seedling:`) or ♻️ (`:recycle:`) for future improvements or indications of technical debt
- ⛏ (`:pick:`) for minor or nitpick changes
Hello,
