charly ssh
| Served by | plugin-ssh |
| Placement | compiled-in (in-process) |
| Version | 2026.209.0000 |
ssh is a command word served by the plugin-ssh plugin candy. This plugin is listed in charly/charly.yml’s compiled_plugins:, so its providers are compiled into the charly binary and register in-process.
About the plugin that serves it
Section titled “About the plugin that serves it”COMPILED-IN charly COMMAND-class plugin owning the externalized charly ssh tunnel spice/vnc command (#118 loader+check-tail cone). It opens an SSH-forwarded local
SPICE/VNC endpoint pointing at a VM’s display on a remote libvirt host, for clients that
don’t natively understand qemu+ssh:// (standalone remote-viewer with a TCP addr,
TigerVNC, Spicy). virt-manager and remote-viewer --connect qemu+ssh://… do NOT need it.
The plugin owns the command end to end: the kong grammar (SshCmd → tunnel spice/vnc), the sshx SSH-tunnel machinery, the vmshared libvirt-URI parse, and the kit UNIX→TCP bridge — all sdk libraries. The ONE thing it cannot do itself is the display-endpoint RESOLVE (go-libvirt, out-of-process): it reaches verb:libvirt DIRECTLY over its in-proc reverse channel via InvokeProvider, so no charly-core symbol crosses the boundary.
ssh is COMPILED-IN (listed in charly/charly.yml compiled_plugins) BECAUSE its Invoke(OpRun) needs the in-proc reverse channel — threaded by dispatchInProcCommand — to reach verb:libvirt. The out-of-process CliMain path has no reverse channel, so it errors. command:ssh dispatches through the compiled-in registry path (registerCompiledPlugin → resolve(ClassCommand,“ssh”) → dispatchInProcCommand → Invoke(OpRun)); NewMeta advertises command:ssh with no plugin_input (the args are plain CLI tokens kong-parsed into SshCmd).
Run charly ssh --help for the live flag grammar.