Skip to content

v0.2.0 — Linux clients and password-only SSH hosts

Latest
Latest

Choose a tag to compare

View all tags
@jaycverg jaycverg released this 05 Sep 03:02
v0.2.0
816874e

Adds Linux clients and makes password-only SSH hosts work with no setup.

Added

  • Linux clients (beta). The clipboard is read through wl-paste on Wayland or xclip on X11, covering text/uri-list plus the GNOME and legacy Nautilus flavors, and PNG screenshots. Copy a file in Files or Dolphin and paste it into the terminal exactly as on macOS.
  • Password-only hosts work without configuration. When ssh rejects the upload for lack of credentials, clip2remote asks for the password once and opens a background master connection; ControlPersist keeps it warm so later pastes reuse it silently. The password is never written to disk and never placed in an environment variable — it travels through a 0600 FIFO in a 0700 directory, read once by a generated askpass helper, and the directory is removed immediately. Requires OpenSSH 8.4+ on the client (for SSH_ASKPASS_REQUIRE); tunable via clip2remote.masterPersistSeconds.
  • Ctrl+Shift+V also triggers the paste, the conventional terminal paste on Linux.
  • A missing wl-clipboard/xclip, or no graphical session, is reported once per session with the install command instead of failing silently on every paste.

Fixed

  • Uploads no longer demand a second authentication on a password-only host. reuseSshConnection used to impose its own ControlPath, overriding any multiplexing the user had configured — so an ssh master already authenticated for the window (the one Remote-SSH holds open) was ignored, and the upload tried to open a fresh connection that BatchMode=yes cannot authenticate. clip2remote now consults ssh -G <host> and inherits the user's master. Affects every client platform, not just Linux.
  • A remote window with no resolvable SSH target no longer inserts client-side paths. Connecting to a host without opening a folder leaves no authority to read, so the window looked local and (with enableInLocalWindows on) injected the client's own paths into a terminal on the remote, where they do not exist. Such a window now reports the problem instead.
  • Staged screenshots live under the OS temp dir rather than a hardcoded /tmp.

Verified

  • macOS client — macOS 26.5.2 (25F84), VS Code 1.131.0, Node 24.11.1. Unit suite 67/67. Live: a Finder-copied file pasted into a Remote-SSH terminal — uploaded, deduplicated on repeat, remote path inserted — against both a Linux and a macOS remote.
  • Linux client (beta) — Ubuntu 24.04.4 LTS, Node 24.11.1, wl-clipboard 2.2.1 and xclip 0.13 present. Unit suite 67/67. The clipboard backend has not been run against a live desktop session. That is what beta means here.
  • Windows client — not supported in this release; Ctrl+V falls through to VS Code's own paste.

Full notes: CHANGELOG.md

Assets 3
Loading