SSH agent approval prompt: surface which app, which host, which signature

[passabilities]

Select Topic Area

✅ Code Contribution Proposal

Code Contribution Proposal

I would like to propose a richer SSH agent approval prompt for the desktop app that surfaces the requesting application, the target host, and the SSH server's host key so users can make an informed approve/deny decision.

Today the prompt only says "ssh is requesting access to {key} to authenticate to a server" — the user can't tell whether the request came from their git push, VSCode Remote-SSH, an Ansible run, or a malicious local process. This gap was flagged in #13535 and closed with a request to open a code proposal, which is what this is.

I built a working prototype (all client tests green, cross-platform Rust + TS): PR #20875 — closed by @dwbit pending this discussion, and correctly noted it targeted the older V1 agent code. Would re-implement on V2 with team input.

What I am proposing (v1)

Enrich the existing approval dialog with locally-derivable context — no DNS, no reverse lookups, no network calls:

• Requesting application — process tree via sysinfo (leaf process + non-shell ancestor). e.g. surfaces Visual Studio Code → ssh instead of just ssh.
• Target host — parsed from the requester's argv (ssh user@host) and cross-referenced with ~/.ssh/known_hosts for a Verified badge when the key is recognized.
• Host key fingerprint — SHA256:… from the OpenSSH session-bind@openssh.com extension.
• Trust labels — the hostname source is displayed as Verified (matches known_hosts), Unverified (from argv only — a process can lie), or fingerprint-only.
• Behind a feature flag; when off, the prompt is byte-identical to today's.

Verified GitHub host — process chain reveals GitKraken as the real requester:

What I am NOT proposing for v1

• No changes to the SSH protocol or bitwarden_russh.
• No new telemetry.
• No network calls of any kind — all derivation is local.
• No changes to the settings-level "Ask for authorization" behavior.
• No changes to the V1 agent path itself beyond deprecation — V2 is the target.

Open questions I'd like feedback on before writing V2 code

1. Direction check — is a richer prompt something the team wants at all, or is the minimal current design intentional?
2. argv display — this is the most sensitive piece since argv can carry secrets (--token=…). Show it always, only under a deeper disclosure, scrub known-sensitive flags, or omit entirely?
3. Trust-label rendering — I used inline green/amber badges; is there an existing pattern in the design system that fits better?

Happy to walk through the V1 implementation on the closed PR or drop the current approach entirely if the team has a different direction in mind.

[github-actions[bot]]

✨ Thank you for your code contribution proposal! While the Bitwarden team reviews your submission, we encourage you to check out our contribution guidelines.

Please ensure that your code contribution includes a detailed description of what you would like to contribute, along with any relevant screenshots and links to existing feature requests. This information helps us gather feedback from the community and Bitwarden team members before you start writing code.

To keep discussions focused, posts that do not include a proposal for a code contribution will be removed.

• 💡 For feature requests and general discussion, please visit the Bitwarden Community Forums.
• ℹ️ For questions and support, visit the Bitwarden Help Center.
• 🐛 To report a potential bug, please visit the corresponding repo. Server | Clients | iOS | Android

Thank you for contributing to Bitwarden!