The direct HKCR\ssh\shell\open\command write (what SshHandler and the
initial Rust port both did) doesn't actually get honored once a
UserChoice already exists for the ssh scheme, which is the normal
state on Windows 10/11 — so registration silently no-ops from the
user's perspective.
Switch to the same "Default Programs" capability registration
openssh_protocol_handler.bat uses: a dedicated ProgID with
Capabilities\UrlAssociations plus a HKLM\SOFTWARE\RegisteredApplications
entry, so the app actually shows up in and can be selected from
Settings > Apps > Default Apps > "Choose default apps by link type".
Uses its own identifier, ssh_handler_rs, distinct from the batch
script's ssh_custom_handler so the two don't collide.
Verified end-to-end under Wine: registry keys land exactly as
expected (checked via `wine reg query`), and both the setup and
connect dialogs still render correctly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GYCT2RpUjFfBfp6CD4rREw
Raw Win32 rewrite (windows-rs + a native dialog resource, no GUI
framework) of SshHandler, aimed at eliminating .NET's ~150MB
self-contained payload and CLR startup cost for what's just a
click-triggered dialog + process launch. Release build cross-compiles
to a ~250KB binary. Same behavior as the WinForms version: registry
setup mode, target parsing/editing dialog, legacy-algorithm option,
launches ssh.exe via ShellExecuteW.
Verified functionally under Wine (registry-setup prompt and the
connect dialog both render and round-trip correctly); real Windows
cold-start numbers still need to be gathered on actual hardware.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GYCT2RpUjFfBfp6CD4rREw
This script handles SSH links, allowing installation, uninstallation, and debugging of the SSH protocol handler on Linux systems. It includes user notifications and checks for proper configuration.
Claude
ergosteurandGitHub